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]

Message-ID: <c8185887-36a0-6287-5776-d17a0c7b8d53@mellanox.com>
Date:   Mon, 30 Mar 2020 05:30:18 +0000
From:   Parav Pandit <parav@...lanox.com>
To:     Jiri Pirko <jiri@...nulli.us>, Jakub Kicinski <kuba@...nel.org>
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

On 3/27/2020 1:17 PM, Jiri Pirko wrote:
> Thu, Mar 26, 2020 at 09:30:01PM CET, kuba@...nel.org wrote:
>> On Thu, 26 Mar 2020 15:51:46 +0100 Jiri Pirko wrote:
>>> Thu, Mar 26, 2020 at 03:47:09PM CET, jiri@...nulli.us wrote:
>>>>>>>>>> $ devlink slice show
>>>>>>>>>> pci/0000:06:00.0/0: flavour physical pfnum 0 port 0 state active
>>>>>>>>>> pci/0000:06:00.0/1: flavour physical pfnum 1 port 1 state active
>>>>>>>>>> pci/0000:06:00.0/2: flavour pcivf pfnum 0 vfnum 0 port 2 hw_addr 10:22:33:44:55:66 state active
>>>>>>>>>> pci/0000:06:00.0/3: flavour pcivf pfnum 0 vfnum 1 port 3 hw_addr aa:bb:cc:dd:ee:ff state active
>>>>>>>>>> pci/0000:06:00.0/4: flavour pcivf pfnum 1 vfnum 0 port 4 hw_addr 10:22:33:44:55:88 state active
>>>>>>>>>> pci/0000:06:00.0/5: flavour pcivf pfnum 1 vfnum 1 port 5 hw_addr 10:22:33:44:55:99 state active
>>>>>>>>>> pci/0000:06:00.0/6: flavour pcivf pfnum 1 vfnum 2      
>>>>>>>>>
>>>>>>>>> What are slices?      
>>>>>>>>
>>>>>>>> Slice is basically a piece of ASIC. pf/vf/sf. They serve for
>>>>>>>> configuration of the "other side of the wire". Like the mac. Hypervizor
>>>>>>>> admin can use the slite to set the mac address of a VF which is in the
>>>>>>>> virtual machine. Basically this should be a replacement of "ip vf"
>>>>>>>> command.    
>>>>>>>
>>>>>>> I lost my mail archive but didn't we already have a long thread with
>>>>>>> Parav about this?    
>>>>>>
>>>>>> I believe so.  
>>>>>
>>>>> Oh, well. I still don't see the need for it :( If it's one to one with
>>>>> ports why add another API, and have to do some cross linking to get
>>>> >from one to the other?
>>>>>
>>>>> I'd much rather resources hanging off the port.  
>>>>
>>>> Yeah, I was originally saying exactly the same as you do. However, there
>>>> might be slices that are not related to any port. Like NVE. Port does
>>>> not make sense in that world. It is just a slice of device.
>>>> Do we want to model those as "ports" too? Maybe. What do you think?  
>>>
>>> Also, the slice is to model "the other side of the wire":
>>>
>>> eswitch - devlink_port ...... slice
>>>
>>> If we have it under devlink port, it would probably
>>> have to be nested object to have the clean cut.
>>
>> 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.
> 
devlink slice represents a PF/VF/SF. This means that a given function
can have an rdma, eth and more class of device.
So port of a slice is both eth+rdma (not either or).