From: Jason Gunthorpe <jgg@mellanox.com> To: Jason Wang <jasowang@redhat.com> Cc: mst@redhat.com, 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: Thu, 13 Feb 2020 11:05:42 -0400 [thread overview] Message-ID: <20200213150542.GW4271@mellanox.com> (raw) In-Reply-To: <ebaea825-5432-65e2-2ab3-720a8c4030e7@redhat.com> On Thu, Feb 13, 2020 at 10:58:44PM +0800, Jason Wang wrote: > > On 2020/2/13 下午9:41, Jason Gunthorpe wrote: > > On Thu, Feb 13, 2020 at 11:34:10AM +0800, Jason Wang wrote: > > > > > > You have dev, type or > > > > class to choose from. Type is rarely used and doesn't seem to be used > > > > by vdpa, so class seems the right choice > > > > > > > > Jason > > > Yes, but my understanding is class and bus are mutually exclusive. So we > > > can't add a class to a device which is already attached on a bus. > > While I suppose there are variations, typically 'class' devices are > > user facing things and 'bus' devices are internal facing (ie like a > > PCI device) > > > Though all vDPA devices have the same programming interface, but the > semantic is different. So it looks to me that use bus complies what > class.rst said: > > " > > Each device class defines a set of semantics and a programming interface > that devices of that class adhere to. Device drivers are the > implementation of that programming interface for a particular device on > a particular bus. > > " Here we are talking about the /dev/XX node that provides the programming interface. All the vdpa devices have the same basic chardev interface and discover any semantic variations 'in band' > > So why is this using a bus? VDPA is a user facing object, so the > > driver should create a class vhost_vdpa device directly, and that > > driver should live in the drivers/vhost/ directory. > > This is because we want vDPA to be generic for being used by different > drivers which is not limited to vhost-vdpa. E.g in this series, it allows > vDPA to be used by kernel virtio drivers. And in the future, we will > probably introduce more drivers in the future. I don't see how that connects with using a bus. Every class of virtio traffic is going to need a special HW driver to enable VDPA, that special driver can create the correct vhost side class device. > > For the PCI VF case this driver would bind to a PCI device like > > everything else > > > > For our future SF/ADI cases the driver would bind to some > > SF/ADI/whatever device on a bus. > > All these driver will still be bound to their own bus (PCI or other). And > what the driver needs is to present a vDPA device to virtual vDPA bus on > top. Again, I can't see any reason to inject a 'vdpa virtual bus' on top. That seems like mis-using the driver core. Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@mellanox.com> To: Jason Wang <jasowang@redhat.com> Cc: kvm@vger.kernel.org, mst@redhat.com, mhabets@solarflare.com, virtualization@lists.linux-foundation.org, rob.miller@broadcom.com, lulu@redhat.com, hanand@xilinx.com, hch@infradead.org, eperezma@redhat.com, haotian.wang@sifive.com, shahafs@mellanox.com, parav@mellanox.com, jiri@mellanox.com, xiao.w.wang@intel.com, stefanha@redhat.com, zhihong.wang@intel.com, rdunlap@infradead.org, linux-kernel@vger.kernel.org, maxime.coquelin@redhat.com, netdev@vger.kernel.org, lingshan.zhu@intel.com Subject: Re: [PATCH V2 3/5] vDPA: introduce vDPA bus Date: Thu, 13 Feb 2020 11:05:42 -0400 [thread overview] Message-ID: <20200213150542.GW4271@mellanox.com> (raw) In-Reply-To: <ebaea825-5432-65e2-2ab3-720a8c4030e7@redhat.com> On Thu, Feb 13, 2020 at 10:58:44PM +0800, Jason Wang wrote: > > On 2020/2/13 下午9:41, Jason Gunthorpe wrote: > > On Thu, Feb 13, 2020 at 11:34:10AM +0800, Jason Wang wrote: > > > > > > You have dev, type or > > > > class to choose from. Type is rarely used and doesn't seem to be used > > > > by vdpa, so class seems the right choice > > > > > > > > Jason > > > Yes, but my understanding is class and bus are mutually exclusive. So we > > > can't add a class to a device which is already attached on a bus. > > While I suppose there are variations, typically 'class' devices are > > user facing things and 'bus' devices are internal facing (ie like a > > PCI device) > > > Though all vDPA devices have the same programming interface, but the > semantic is different. So it looks to me that use bus complies what > class.rst said: > > " > > Each device class defines a set of semantics and a programming interface > that devices of that class adhere to. Device drivers are the > implementation of that programming interface for a particular device on > a particular bus. > > " Here we are talking about the /dev/XX node that provides the programming interface. All the vdpa devices have the same basic chardev interface and discover any semantic variations 'in band' > > So why is this using a bus? VDPA is a user facing object, so the > > driver should create a class vhost_vdpa device directly, and that > > driver should live in the drivers/vhost/ directory. > > This is because we want vDPA to be generic for being used by different > drivers which is not limited to vhost-vdpa. E.g in this series, it allows > vDPA to be used by kernel virtio drivers. And in the future, we will > probably introduce more drivers in the future. I don't see how that connects with using a bus. Every class of virtio traffic is going to need a special HW driver to enable VDPA, that special driver can create the correct vhost side class device. > > For the PCI VF case this driver would bind to a PCI device like > > everything else > > > > For our future SF/ADI cases the driver would bind to some > > SF/ADI/whatever device on a bus. > > All these driver will still be bound to their own bus (PCI or other). And > what the driver needs is to present a vDPA device to virtual vDPA bus on > top. Again, I can't see any reason to inject a 'vdpa virtual bus' on top. That seems like mis-using the driver core. Jason _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2020-02-13 15:05 UTC|newest] Thread overview: 47+ 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 [this message] 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 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-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 2020-02-14 3:23 ` Jason Wang 2020-02-14 3:23 ` Jason Wang 2020-02-14 13:52 ` Jason Gunthorpe 2020-02-17 6:08 ` Jason Wang 2020-02-17 6:08 ` Jason Wang 2020-02-18 13:56 ` Jason Gunthorpe 2020-02-18 13:56 ` Jason Gunthorpe 2020-02-19 2:59 ` Tiwei Bie 2020-02-19 2:59 ` Tiwei Bie 2020-02-19 5:35 ` Jason Wang 2020-02-19 5:35 ` Jason Wang 2020-02-19 12:53 ` Jason Gunthorpe 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-10 13:34 ` Jason Gunthorpe 2020-02-11 3:04 ` Jason Wang 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=20200213150542.GW4271@mellanox.com \ --to=jgg@mellanox.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=jasowang@redhat.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.