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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 19 Nov 2019 15:37:03 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     Parav Pandit <parav@...lanox.com>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Cc:     Dave Ertman <david.m.ertman@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "sassmann@...hat.com" <sassmann@...hat.com>,
        "jgg@...pe.ca" <jgg@...pe.ca>, Kiran Patil <kiran.patil@...el.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Alex Williamson <alex.williamson@...hat.com>,
        "Bie, Tiwei" <tiwei.bie@...el.com>
Subject: Re: [net-next v2 1/1] virtual-bus: Implementation of Virtual Bus


On 2019/11/19 下午3:13, Parav Pandit wrote:
>> From: Jason Wang <jasowang@...hat.com>
>> 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@mellanox.com/
>