Mon, Mar 04, 2019 at 05:59:04AM CET, parav@mellanox.com wrote:

quoted

-----Original Message-----
From: netdev-owner@vger.kernel.org <redacted> On
Behalf Of Jiri Pirko
Sent: Wednesday, February 27, 2019 6:17 AM
To: Jakub Kicinski <redacted>
Cc: davem@davemloft.net; oss-drivers@netronome.com;
netdev@vger.kernel.org
Subject: Re: [PATCH net-next 2/8] devlink: add PF and VF port flavours

Tue, Feb 26, 2019 at 07:24:30PM CET, jakub.kicinski@netronome.com wrote:

quoted

Current port flavours cover simple switches and DSA.  Add PF and VF
flavours to cover "switchdev" SR-IOV NICs.

Example devlink user space output:

$ devlink port
pci/0000:82:00.0/0: type eth netdev p4p1 flavour physical
pci/0000:82:00.0/10000: type eth netdev eth0 flavour pcie_pf pf 0
pci/0000:82:00.0/10001: type eth netdev eth1 flavour pcie_vf pf 0 vf 0
pci/0000:82:00.0/10002: type eth netdev eth2 flavour pcie_vf pf 0 vf 1

A given port is of its parent device.
In current scenario, its PF or VF.
Hence it should be device attribute and not a port attribute.

I think that this works. You have VF_rep ports, PF_rep ports and
PHYSICAL ports. In mlxsw for example, there are only PHYSICAL ports.
In sr-iov world, there is also a PHYSICAL port on the eswitch. The
others are either facing PF of VF. Looks accurate. I don't see any need
for "devlink dev" flavour.

So devlink dev show command have to show what device flavour is.
Is it well known PCI VF or PF or something else.
It will show subdev device attribute and its parent PCI (PF/VF) devlink device.
So we should have device flovour as PCI_PF or PCI_VF or SUBDEV.

Again VF number showcasing here is very restrictive model.
Every PF/VF/Subdev represents its own 'port' and it is connected to eswitch 'port'.
Instead of showing VF here, it must be this 'port' or 'link' number that gives right view.
Which netdev represents which VF is already linked in the VF rep-netdev sysfs property.

I think you confuse the eswtich ports (in Jakub's output it's them) and
the actual VF.

So flavour should be something like 'hostport' and when port is registered for the eswitch side it should be 'switchport'.
With this there is very clear picture of which hostport is connected to which eswitch port.
Just like how we see in the physical world.