On 2020/2/13 下午11:05, Jason Gunthorpe wrote:
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.
I'm confused here, are you suggesting to use class to create char device
in vhost-vdpa? That's fine but the comment should go for vhost-vdpa patch.
All the vdpa devices have the same basic
chardev interface and discover any semantic variations 'in band'
That's not true, char interface is only used for vhost. Kernel virtio
driver does not need char dev but a device on the virtio bus.
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.
This is demonstrated in the virito-vdpa driver. So if you want to use
kernel virito driver for vDPA device, a bus is most straight forward.
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.
Are you saying, e.g it's the charge of IFCVF driver to create vhost char
dev and other stuffs?
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.
I don't think so. Vhost is not the only programming interface for vDPA.
We don't want a device that can only work for userspace drivers and only
have a single set of userspace APIs.
Thanks
Jason
