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]

Message-ID: <AM0PR05MB486605742430D120769F6C45D14C0@AM0PR05MB4866.eurprd05.prod.outlook.com>
Date:   Tue, 19 Nov 2019 15:14:40 +0000
From:   Parav Pandit <parav@...lanox.com>
To:     Jason Wang <jasowang@...hat.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



> From: Jason Wang <jasowang@...hat.com>
> Sent: Tuesday, November 19, 2019 1:37 AM
> 
> 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.
> 

Nop. Devlink is NOT net specific. It works at the bus/device level.
Any block/scsi/crypto can register devlink instance and implement the necessary ops as long as device has bus.