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]

Message-ID: <20180322233550.GE6544@lunn.ch>
Date:   Fri, 23 Mar 2018 00:35:50 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, idosch@...lanox.com,
        jakub.kicinski@...ronome.com, mlxsw@...lanox.com,
        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, dsahern@...il.com, vijaya.guvva@...ium.com,
        satananda.burla@...ium.com, raghu.vatsavayi@...ium.com,
        felix.manlunas@...ium.com, gospo@...adcom.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 11:55:10AM +0100, 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.
> 
> 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

Hi Jiri

Can you point me to towards your iproute2 patch to make use of the new
properties.

> The indexes are weird numbers now. That needs to be fixed. Also, netdev
> renaming does not work correctly for me now for some reason.
> Also, there is one extra port that I don't understand what
> is the purpose for it - something nfp specific perhaps.
> 
> The desired output should look like this:
> # devlink port
> pci/0000:05:00.0/0: type eth netdev enp5s0np0 flavour physical number 0
> pci/0000:05:00.0/1: type eth netdev enp5s0np1 flavour physical number 1
> pci/0000:05:00.0/2: type eth netdev enp5s0npf0 flavour pf_rep number 0
> pci/0000:05:00.0/3: type eth netdev enp5s0nvf0 flavour vf_rep number 0
> pci/0000:05:00.0/4: type eth netdev enp5s0nvf1 flavour vf_rep number 1
> pci/0000:05:00.0/5: type eth netdev enp5s0nvf2 flavour vf_rep number 2
> pci/0000:05:00.0/6: type eth netdev enp5s0nvf3 flavour vf_rep number 3
> 
> As you can see, the netdev names are generated according to the flavour
> and port number. In case the port is split, the split subnumber is also
> included.

This naming is something we won't want with DSA. We get the port names
from device tree, and they are supposed to reflect the name of the
port printed on the label on the case. So this is often wan, lan0,
lan1, lan2, lan3, etc. That is much more intuitive than enp5s0.

      Andrew