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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 3 May 2020 19:12:18 -0700 From: "Samudrala, Sridhar" <sridhar.samudrala@...el.com> To: Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org Cc: davem@...emloft.net, kuba@...nel.org, 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 Subject: Re: [RFC v2] current devlink extension plan for NICs On 5/1/2020 2:14 AM, Jiri Pirko wrote: > Hi all. > > First, I would like to apologize for very long email. But I think it > would be beneficial to the see the whole picture, where we are going. > > Currently we are working internally on several features with > need of extension of the current devlink infrastructure. I took a stab > at putting it all together in a single txt file, inlined below. > > Most of the stuff is based on a new port sub-object called "func" > (called "slice" previously" and "subdev" originally in Yuval's patchsets > sent some while ago). > > The text describes how things should behave and provides a draft > of user facing console input/outputs. I think it is important to clear > that up before we go in and implement the devlink core and > driver pieces. > > I would like to ask you to read this and comment. Especially, I would > like to ask vendors if what is described fits the needs of your > NIC/e-switch. > > Please note that something is already implemented, but most of this > isn't (see "what needs to be implemented" section). > > v1->v2 > - mainly move from separate slice object into port/func subobject > - couple of small fixes here and there > <snip> > > > > ================================================================== > || || > || Port func user cmdline API draft || > || || > ================================================================== > > Note that some of the "devlink port" attributes may be forgotten or misordered. > > Funcs are created as sub-objects of ports where it makes sense to have them > The driver takes care of that. The "func" is a handle to configure "the other > side of the wire". The original port object has port leve properties, > the new "func" sub-object on the other hand has device level properties". > > This is example for the HOST A from the example above: > > $ devlink port show > pci/0000:06:00.0/0: flavour physical pfnum 0 type eth netdev enp6s0f0np1 > pci/0000:06:00.0/1: flavour physical pfnum 1 type eth netdev enp6s0f0np2 > pci/0000:06:00.0/2: flavour pcipf pfnum 2 type eth netdev enp6s0pf2 > func: hw_addr 10:22:33:44:55:66 state active > pci/0000:06:00.0/3: flavour pcivf pfnum 2 vfnum 0 type eth netdev enp6s0pf2vf0 > func: hw_addr 10:22:33:44:55:77 state active > pci/0000:06:00.0/4: flavour pcivf pfnum 0 vfnum 0 type eth netdev enp6s0pf0vf0 > func: hw_addr 10:22:33:44:55:88 state active > pci/0000:06:00.0/5: flavour pcisf pfnum 0 sfnum 1 type eth netdev enp6s0pf0sf1 > func: hw_addr 10:22:33:44:55:99 state active > pci/0000:06:00.0/6: flavour pcivf pfnum 1 vfnum 2 type nvme > func: state active I am trying to understand how the current implementation of 'devlink port' is being refactored to support this new model. Today 'devlink port show' on a system with 2 port mlx5 NIC with 1 VFs created on each PF shows pci/0000:af:00.0/1: type eth netdev enp175s0f0np0 flavour physical port 0 pci/0000:af:00.1/1: type eth netdev enp175s0f1np1 flavour physical port 1 pci/0000:af:00.2/1: type eth netdev enp175s0f2np0 flavour virtual port 0 pci/0000:af:08.2/1: type eth netdev enp175s8f2np0 flavour virtual port 0 Can you tell me how this will be represented in the new model? It looks like you are assigning a pfnum to physical port as well as PCI PF. However, i am little confused as both pfnum 0 and pfnum 1 which seem to be 2 physical ports have the same bus/dev/func 06:00.0 and also the VF ports. Thanks Sridhar
Powered by blists - more mailing lists