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:   Wed, 20 Nov 2019 12:07:59 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     Parav Pandit <parav@...lanox.com>
Cc:     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>,
        "jgg@...pe.ca" <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


On 2019/11/20 上午11:38, Parav Pandit wrote:
>
>> From: Jason Wang <jasowang@...hat.com>
>> Sent: Tuesday, November 19, 2019 9:15 PM
>>
>> ----- Original Message -----
>>>
>>>> From: Jason Wang <jasowang@...hat.com>
>>>> Sent: Tuesday, November 19, 2019 1:37 AM
>>>>
>>> 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.
>>
> It is under iproute2 tool but it is not limited to networking.
> Though today most users are networking drivers.
>
> I do not know how ovs offloads are done without devlink by other vendors doing in-kernel drivers.
>
>> So technically it could be extended but how hard it can be achieved in reality?
>>
> What are the missing things?
> I am extending it for subfunctions lifecycle. I see virtio as yet another flavour/type of subfunction.


Just to make sure we're on the same page. Sub function is only one of 
the possible cases for virtio. As I replied in another thread, we had 
already had NIC that does virtio at PF or VF level. For reality, I mean 
the effort spent on convincing all vendors to use devlink.


>
>> I still don't see why devlink is conflicted with GUID/sysfs, you can hook sysfs
> It is not conflicting. If you look at what all devlink infrastructure provides, you will end up replicating all of it via sysfs..


To clarify, I'm not saying duplicating all stuffs through sysfs. I meant 
whether we can:

1) create sub fucntion and do must to have pre configuration through 
devlink
2) only after sub function is created one more available instance was 
added and shown through sysfs
3) user can choose to create and use that mdev instance as it did for 
other type of device like vGPU
4) devlink can still use to report other stuffs


> It got syscaller support too, which is great for validation.
> I have posted subfunction series with mdev and used devlink for all rest of the esw and mgmt. interface to utilize it.
>
> sriov via sysfs and devlink sriov/esw handling has some severe locking issues, mainly because they are from two different interfaces.
>
>> events to devlink or do post or pre configuration through devlink. This is much
>> more easier than forcing all vendors to use devlink.
>>
> It is not about forcing. It is about leveraging existing kernel framework available without reinventing the wheel.
> I am 100% sure, implementing health, dumps, traces, reporters, syscaller, monitors, interrupt configs, extending params via sysfs will be no-go.
> sysfs is not meant for such things anymore. Any modern device management will need all of it.


I'm not familiar with other type of devices, but they should have their 
own vendor specific way to do that. That the real problems.

Thanks