From: Jason Wang <jasowang@redhat.com>
To: Jason Gunthorpe <jgg@mellanox.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
virtualization@lists.linux-foundation.org,
netdev@vger.kernel.org, tiwei.bie@intel.com,
maxime.coquelin@redhat.com, cunming.liang@intel.com,
zhihong.wang@intel.com, rob.miller@broadcom.com,
xiao.w.wang@intel.com, haotian.wang@sifive.com,
lingshan.zhu@intel.com, eperezma@redhat.com, lulu@redhat.com,
parav@mellanox.com, kevin.tian@intel.com, stefanha@redhat.com,
rdunlap@infradead.org, hch@infradead.org, aadam@redhat.com,
jiri@mellanox.com, shahafs@mellanox.com, hanand@xilinx.com,
mhabets@solarflare.com
Subject: Re: [PATCH V2 3/5] vDPA: introduce vDPA bus
Date: Fri, 14 Feb 2020 12:39:48 +0800 [thread overview]
Message-ID: <da994ac0-6f44-109f-962e-5df9cfbc3221@redhat.com> (raw)
In-Reply-To: <20200213161320.GY4271@mellanox.com>
On 2020/2/14 上午12:13, Jason Gunthorpe wrote:
> On Thu, Feb 13, 2020 at 10:59:34AM -0500, Michael S. Tsirkin wrote:
>> On Thu, Feb 13, 2020 at 11:51:54AM -0400, Jason Gunthorpe wrote:
>>> The 'class' is supposed to provide all the library functions to remove
>>> this duplication. Instead of plugging the HW driver in via some bus
>>> scheme every subsystem has its own 'ops' that the HW driver provides
>>> to the subsystem's class via subsystem_register()
>> Hmm I'm not familiar with subsystem_register. A grep didn't find it
>> in the kernel either ...
> I mean it is the registration function provided by the subsystem that
> owns the class, for instance tpm_chip_register(),
> ib_register_device(), register_netdev(), rtc_register_device() etc
>
> So if you have some vhost (vhost net?) class then you'd have some
> vhost_vdpa_init/alloc(); vhost_vdpa_register(), sequence
> presumably. (vs trying to do it with a bus matcher)
>
> I recommend to look at rtc and tpm for fairly simple easy to follow
> patterns for creating a subsystem in the kernel. A subsystem owns a class,
> allows HW drivers to plug in to it, and provides a consistent user
> API via a cdev/sysfs/etc.
>
> The driver model class should revolve around the char dev and sysfs
> uABI - if you enumerate the devices on the class then they should all
> follow the char dev and sysfs interfaces contract of that class.
>
> Those examples show how to do all the refcounting semi-sanely,
> introduce sysfs, cdevs, etc.
>
> I thought the latest proposal was to use the existing vhost class and
> largely the existing vhost API, so it probably just needs to make sure
> the common class-wide stuff is split from the 'driver' stuff of the
> existing vhost to netdev.
Still, netdev is only one of the type we want to support. And we can not
guarantee or forecast that vhost is the only API that is used.
Let's take virtio as an example, it is implemented through a bus which
allows different subsystems on top. And it can provide a variety of
different uAPIs. For best performance, VFIO could be used for userspace
drivers, but it requires the bus has support from VFIO.
For vDPA devices, it's just the same logic. A bus allows different
drivers and subsystems on top. One of the subsystem could be vhost that
provides a unified API for userspace driver.
Thanks
>
> Jason
>
next prev parent reply other threads:[~2020-02-14 4:40 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-10 3:56 [PATCH V2 0/5] vDPA support Jason Wang
2020-02-10 3:56 ` [PATCH V2 1/5] vhost: factor out IOTLB Jason Wang
2020-02-10 3:56 ` [PATCH V2 2/5] vringh: IOTLB support Jason Wang
2020-02-10 3:56 ` [PATCH V2 3/5] vDPA: introduce vDPA bus Jason Wang
2020-02-11 13:47 ` Jason Gunthorpe
2020-02-12 7:55 ` Jason Wang
2020-02-12 12:51 ` Jason Gunthorpe
2020-02-13 3:34 ` Jason Wang
2020-02-13 13:41 ` Jason Gunthorpe
2020-02-13 14:58 ` Jason Wang
2020-02-13 15:05 ` Jason Gunthorpe
2020-02-13 15:41 ` Michael S. Tsirkin
2020-02-13 15:51 ` Jason Gunthorpe
2020-02-13 15:56 ` Michael S. Tsirkin
2020-02-13 16:24 ` Jason Gunthorpe
2020-02-14 4:05 ` Jason Wang
2020-02-14 14:04 ` Jason Gunthorpe
2020-02-17 6:07 ` Jason Wang
2020-02-13 15:59 ` Michael S. Tsirkin
2020-02-13 16:13 ` Jason Gunthorpe
2020-02-14 4:39 ` Jason Wang [this message]
2020-02-14 3:23 ` Jason Wang
2020-02-14 13:52 ` Jason Gunthorpe
2020-02-17 6:08 ` Jason Wang
2020-02-18 13:56 ` Jason Gunthorpe
2020-02-19 2:59 ` Tiwei Bie
2020-02-19 5:35 ` Jason Wang
2020-02-19 12:53 ` Jason Gunthorpe
2020-02-10 3:56 ` [PATCH V2 4/5] virtio: introduce a vDPA based transport Jason Wang
2020-02-10 13:34 ` Jason Gunthorpe
2020-02-11 3:04 ` Jason Wang
2020-02-10 3:56 ` [PATCH V2 5/5] vdpasim: vDPA device simulator Jason Wang
2020-02-10 11:23 ` Michael S. Tsirkin
2020-02-11 3:12 ` Jason Wang
2020-02-11 13:52 ` Jason Gunthorpe
2020-02-12 8:27 ` Jason Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=da994ac0-6f44-109f-962e-5df9cfbc3221@redhat.com \
--to=jasowang@redhat.com \
--cc=aadam@redhat.com \
--cc=cunming.liang@intel.com \
--cc=eperezma@redhat.com \
--cc=hanand@xilinx.com \
--cc=haotian.wang@sifive.com \
--cc=hch@infradead.org \
--cc=jgg@mellanox.com \
--cc=jiri@mellanox.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=lingshan.zhu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lulu@redhat.com \
--cc=maxime.coquelin@redhat.com \
--cc=mhabets@solarflare.com \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=parav@mellanox.com \
--cc=rdunlap@infradead.org \
--cc=rob.miller@broadcom.com \
--cc=shahafs@mellanox.com \
--cc=stefanha@redhat.com \
--cc=tiwei.bie@intel.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=xiao.w.wang@intel.com \
--cc=zhihong.wang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).