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: <20200326145146.GX11304@nanopsycho.orion>
Date:   Thu, 26 Mar 2020 15:51:46 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, parav@...lanox.com,
        yuvalav@...lanox.com, jgg@...pe.ca, saeedm@...lanox.com,
        leon@...nel.org, andrew.gospodarek@...adcom.com,
        michael.chan@...adcom.com, moshe@...lanox.com, ayal@...lanox.com,
        eranbe@...lanox.com, vladbu@...lanox.com, kliteyn@...lanox.com,
        dchickles@...vell.com, sburla@...vell.com, fmanlunas@...vell.com,
        tariqt@...lanox.com, oss-drivers@...ronome.com,
        snelson@...sando.io, drivers@...sando.io, aelior@...vell.com,
        GR-everest-linux-l2@...vell.com, grygorii.strashko@...com,
        mlxsw@...lanox.com, idosch@...lanox.com, markz@...lanox.com,
        jacob.e.keller@...el.com, valex@...lanox.com,
        linyunsheng@...wei.com, lihong.yang@...el.com,
        vikas.gupta@...adcom.com, magnus.karlsson@...el.com
Subject: Re: [RFC] current devlink extension plan for NICs

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.