Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation

Thu, Mar 22, 2018 at 08:25:46PM CET, andrew.gospodarek@broadcom.com wrote:

On Thu, Mar 22, 2018 at 01:10:38PM -0600, David Ahern wrote:

quoted

On 3/22/18 11:49 AM, Jiri Pirko wrote:

quoted

Thu, Mar 22, 2018 at 04:34:07PM CET, dsahern@gmail.com wrote:

quoted

On 3/22/18 4:55 AM, Jiri Pirko wrote:

quoted

From: Jiri Pirko <redacted>

This patchset resolves 2 issues we have right now:
1) There are many netdevices / ports in the system, for port, pf, vf
   represenatation but the user has no way to see which is which
2) The ndo_get_phys_port_name is implemented in each driver separatelly,
   which may lead to inconsistent names between drivers.

Similar to ndo_get_phys_port_{name,id}, devlink requires drivers to opt
in with an implementation right, so you can't really force a solution to
the consistent naming.

Yeah, drivers would still have free choice to implemen the ndo
themselves. But most of them, like all sriov switch drivers should use
the devlink helper to have consistent naming. In other words, devlink
helper should be the standard way, in weird cases (like rocker), driver
implements it himself.

That's an assumption that somehow the devlink API will be better
supported than ndo_get_phys_port_{name,id}. Don't get me wrong -- an API
to show the kind of device is needed, but I do not think this enforces
any kind of consistency in naming.

quoted

quoted

quoted

This patchset introduces port flavours which should address the first
problem. I'm testing this with Netronome nfp hardware. When the user
has 2 physical ports, 1 pf, and 4 vfs, he should see something like this:
# devlink port
pci/0000:05:00.0/0: type eth netdev enp5s0np0 flavour physical number 0
pci/0000:05:00.0/268435456: type eth netdev eth0 flavour physical number 0
pci/0000:05:00.0/268435460: type eth netdev enp5s0np1 flavour physical number 1
pci/0000:05:00.0/536875008: type eth netdev eth2 flavour pf_rep number 536875008
pci/0000:05:00.0/536870912: type eth netdev eth1 flavour vf_rep number 0
pci/0000:05:00.0/536870976: type eth netdev eth3 flavour vf_rep number 1
pci/0000:05:00.0/536871040: type eth netdev eth4 flavour vf_rep number 2
pci/0000:05:00.0/536871104: type eth netdev eth5 flavour vf_rep number 3

How about 'kind' instead of flavo{u}r?

Yeah, kind is often used in kernel already with different meaning
git grep kind net/core
I wanted to avoid confusions

Roopa's amendment works as well; I just think flavor / flavour is the
wrong word. Make me thinks of food ... ice cream vs netdevices.

Naming it a 'subtype' could also work.  It's a bit longer than 'kind'
(no longer than 'flavour') and accurately describes the characteristic
of this port.  It also avoids the namespace collision of 'kind' that
Jiri points out.

It also fits with the names used in the PCI world with vendor:device and
subsystem vendor:subsystem device naming used there for further
granularity.

Problem with "subtype" is that it indicates some relation with type.
We have type:
enum devlink_port_type {
        DEVLINK_PORT_TYPE_NOTSET,
        DEVLINK_PORT_TYPE_AUTO,
        DEVLINK_PORT_TYPE_ETH,
        DEVLINK_PORT_TYPE_IB,
};

Does not feel correct to have subtypes VF/PF/VFREP/etc, which really has
no relation to ETH/IB

What about "role"? Also does not sound good to me, as the "role"
indicates that the port can "act" like something.

For me the "flavour/flavor" is still a favourite. Tells how the port tastes
like, in a semi-fun way :)
Also, there is a precedence to this in particle physics:
https://en.wikipedia.org/wiki/Color%E2%80%93flavor_locking
I guess they also had troubles to find the right name :)