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
