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

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]

Date:   Thu, 22 Mar 2018 15:25:46 -0400
From:   Andy Gospodarek <andrew.gospodarek@...adcom.com>
To:     David Ahern <dsahern@...il.com>
Cc:     Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
        davem@...emloft.net, idosch@...lanox.com,
        jakub.kicinski@...ronome.com, mlxsw@...lanox.com, andrew@...n.ch,
        vivien.didelot@...oirfairelinux.com, f.fainelli@...il.com,
        michael.chan@...adcom.com, ganeshgr@...lsio.com,
        saeedm@...lanox.com, simon.horman@...ronome.com,
        pieter.jansenvanvuuren@...ronome.com, john.hurley@...ronome.com,
        dirk.vandermerwe@...ronome.com, alexander.h.duyck@...el.com,
        ogerlitz@...lanox.com, vijaya.guvva@...ium.com,
        satananda.burla@...ium.com, raghu.vatsavayi@...ium.com,
        felix.manlunas@...ium.com, sathya.perla@...adcom.com,
        vasundhara-v.volam@...adcom.com, tariqt@...lanox.com,
        eranbe@...lanox.com, jeffrey.t.kirsher@...el.com
Subject: Re: [patch net-next RFC 00/12] devlink: introduce port flavours and
 common phys_port_name generation

On Thu, Mar 22, 2018 at 01:10:38PM -0600, David Ahern wrote:
> On 3/22/18 11:49 AM, Jiri Pirko wrote:
> > Thu, Mar 22, 2018 at 04:34:07PM CET, dsahern@...il.com wrote:
> >> On 3/22/18 4:55 AM, Jiri Pirko wrote:
> >>> From: Jiri Pirko <jiri@...lanox.com>
> >>>
> >>> 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.
> 
> > 
> > 
> >>
> >>>
> >>> 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.