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



----- Original Message -----
> 
> 
> > 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.
> 

Well, uapi/linux/devlink.h told me:

"
 * include/uapi/linux/devlink.h - Network physical device Netlink interface
"

And the userspace tool was packaged into iproute2, the command was
named as "TC", "PORT", "ESWITCH". All of those were strong hints that it
was network specific. Even for networking, only few vendors choose to
implement this.

So technically it could be extended but how hard it can be achieved in
reality?

I still don't see why devlink is conflicted with GUID/sysfs, you can
hook sysfs events to devlink or do post or pre configuration through
devlink. This is much more easier than forcing all vendors to use
devlink.

Thanks