netdev - Re: [RFC] current devlink extension plan for NICs

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:   Mon, 30 Mar 2020 07:48:39 +0000
From:   Parav Pandit <parav@...lanox.com>
To:     Jakub Kicinski <kuba@...nel.org>, Jiri Pirko <jiri@...nulli.us>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Yuval Avnery <yuvalav@...lanox.com>,
        "jgg@...pe.ca" <jgg@...pe.ca>,
        Saeed Mahameed <saeedm@...lanox.com>,
        "leon@...nel.org" <leon@...nel.org>,
        "andrew.gospodarek@...adcom.com" <andrew.gospodarek@...adcom.com>,
        "michael.chan@...adcom.com" <michael.chan@...adcom.com>,
        Moshe Shemesh <moshe@...lanox.com>,
        Aya Levin <ayal@...lanox.com>,
        Eran Ben Elisha <eranbe@...lanox.com>,
        Vlad Buslov <vladbu@...lanox.com>,
        Yevgeny Kliteynik <kliteyn@...lanox.com>,
        "dchickles@...vell.com" <dchickles@...vell.com>,
        "sburla@...vell.com" <sburla@...vell.com>,
        "fmanlunas@...vell.com" <fmanlunas@...vell.com>,
        Tariq Toukan <tariqt@...lanox.com>,
        "oss-drivers@...ronome.com" <oss-drivers@...ronome.com>,
        "snelson@...sando.io" <snelson@...sando.io>,
        "drivers@...sando.io" <drivers@...sando.io>,
        "aelior@...vell.com" <aelior@...vell.com>,
        "GR-everest-linux-l2@...vell.com" <GR-everest-linux-l2@...vell.com>,
        "grygorii.strashko@...com" <grygorii.strashko@...com>,
        mlxsw <mlxsw@...lanox.com>, Ido Schimmel <idosch@...lanox.com>,
        Mark Zhang <markz@...lanox.com>,
        "jacob.e.keller@...el.com" <jacob.e.keller@...el.com>,
        Alex Vesker <valex@...lanox.com>,
        "linyunsheng@...wei.com" <linyunsheng@...wei.com>,
        "lihong.yang@...el.com" <lihong.yang@...el.com>,
        "vikas.gupta@...adcom.com" <vikas.gupta@...adcom.com>,
        "magnus.karlsson@...el.com" <magnus.karlsson@...el.com>
Subject: Re: [RFC] current devlink extension plan for NICs

Hi Jakub,

On 3/27/2020 10:08 PM, Jakub Kicinski wrote:
> On Fri, 27 Mar 2020 08:47:36 +0100 Jiri Pirko wrote:
>>> So the queues, interrupts, and other resources are also part 
>>> of the slice then?  
>>
>> Yep, that seems to make sense.
>>
>>> How do slice parameters like rate apply to NVMe?  
>>
>> Not really.
>>
>>> Are ports always ethernet? and slices also cover endpoints with
>>> transport stack offloaded to the NIC?  
>>
>> devlink_port now can be either "ethernet" or "infiniband". Perhaps,
>> there can be port type "nve" which would contain only some of the
>> config options and would not have a representor "netdev/ibdev" linked.
>> I don't know.
> 
> I honestly find it hard to understand what that slice abstraction is,
> and which things belong to slices and which to PCI ports (or why we even
> have them).
> 
In an alternative, devlink port can be overloaded/retrofit to do all
things that slice desires to do.
For that matter representor netdev can be overloaded/extended to do what
slice desire to do (instead of devlink port).

Can you please explain why you think devlink port should be overloaded
instead of netdev or any other kernel object?
Do you have an example of such overloaded functionality of a kernel object?
Like why macvlan and vlan drivers are not combined to in single driver
object? Why teaming and bonding driver are combined in single driver
object?...

User should be able to create, configure, deploy, delete a 'portion of
the device' with/without eswitch.
We shouldn't be starting with restrictive/narrow view of devlink port.

Internally with Jiri and others, we also explored the possibility to
have 'mgmtvf', 'mgmtpf',  'mgmtsf' port flavours by overloading port to
do all things as that of slice.
It wasn't elegant enough. Why not create right object?

Additionally devlink port object doesn't go through the same state
machine as that what slice has to go through.
So its weird that some devlink port has state machine and some doesn't.

> With devices like NFP and Mellanox CX3 which have one PCI PF maybe it
> would have made sense to have a slice that covers multiple ports, but
> it seems the proposal is to have port to slice mapping be 1:1. And rate
> in those devices should still be per port not per slice.
> 
Slice can have multiple ports. slice object doesn't restrict it. User
can always split the port for a device, if device support it.

> But this keeps coming back, and since you guys are doing all the work,
> if you really really need it..
>