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 12:46:32 -0400
From:   Jason Gunthorpe <jgg@...pe.ca>
To:     Jason Wang <jasowang@...hat.com>
Cc:     Parav Pandit <parav@...lanox.com>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        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>,
        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 Tue, Nov 19, 2019 at 03:37:03PM +0800, Jason Wang wrote:

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

The driver providing the virtio should really be in control of the
life cycle policy. For net related virtio that is clearly devlink.

Even for block we may find that network storage providers (ie some
HW accelerated virtio-blk-over-ethernet) will want to use devlink to
create a combination ethernet and accelerated virtio-block widget.

This is why the guid life cycle stuff should be in a library that can
be used by the drivers that need it (assuming all drivers don't just
use devlink as Parav proposes)

As always, this is all very hard to tell without actually seeing real
accelerated drivers implement this. 

Your patch series might be a bit premature in this regard.

Jason