Re: [net-next v2 1/1] virtual-bus: Implementation of Virtual Bus

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2019/11/19 下午3:13, Parav Pandit wrote:
From: Jason Wang <jasowang@xxxxxxxxxx>
Subject: Re: [net-next v2 1/1] virtual-bus: Implementation of Virtual Bus


[..]

Probably, for virtio mdev we need more than just matching: life cycle
management, cooperation with VFIO and we also want to be prepared for
the device slicing (like sub functions).
Well I am revising my patches to life cycle sub functions via devlink interface for few reasons, as

(a) avoid mdev bus abuse (still named as mdev in your v13 series, though it is actually for vfio-mdev)


Yes, but it could be simply renamed to "vfio-mdev".


(b) support iommu


That is already supported by mdev.


(c) manage and have coupling with devlink eswitch framework, which is very rich in several aspects


Good point.


(d) get rid of limited sysfs interface for mdev creation, as netlink is standard and flexible to add params etc.


Standard but net specific.



If you want to get a glimpse of old RFC work of my revised series, please refer to [1].


Will do.



Jiri, Jason, me think that even virtio accelerated devices will need eswitch support. And hence, life cycling virtio accelerated devices via devlink makes a lot of sense to us.
This way user has single tool to choose what type of device he want to use (similar to ip link add link type).
So sub function flavour will be something like (virtio or sf).


Networking is only one of the types that is supported in virtio-mdev. The codes are generic enough to support any kind of virtio device (block, scsi, crypto etc). Sysfs is less flexible but type independent. I agree that devlink is standard and feature richer but still network specific. It's probably hard to add devlink to other type of physical drivers. I'm thinking whether it's possible to combine syfs and devlink: e.g the mdev is available only after the sub fuction is created and fully configured by devlink.

Thanks



So I am reviving my old RFC [1] back now in few days as actual patches based on series [2].

[1] https://lkml.org/lkml/2019/3/1/19
[2] https://lore.kernel.org/linux-rdma/20191107160448.20962-1-parav@xxxxxxxxxxxx/






[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux