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: <20180417164209.194902db@cakuba.netronome.com>
Date:   Tue, 17 Apr 2018 16:42:09 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Or Gerlitz <gerlitz.or@...il.com>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        Linux Netdev List <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Ido Schimmel <idosch@...lanox.com>, mlxsw <mlxsw@...lanox.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Michael Chan <michael.chan@...adcom.com>,
        Ganesh Goudar <ganeshgr@...lsio.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Simon Horman <simon.horman@...ronome.com>,
        Pieter Jansen van Vuuren 
        <pieter.jansenvanvuuren@...ronome.com>,
        John Hurley <john.hurley@...ronome.com>,
        Dirk van der Merwe <dirk.vandermerwe@...ronome.com>,
        Alexander Duyck <alexander.h.duyck@...el.com>,
        Or Gerlitz <ogerlitz@...lanox.com>,
        David Ahern <dsahern@...il.com>, vijaya.guvva@...ium.com,
        "Burla, Satananda" <satananda.burla@...ium.com>,
        "Vatsavayi, Raghu" <raghu.vatsavayi@...ium.com>,
        "Manlunas, Felix" <felix.manlunas@...ium.com>,
        Andy Gospodarek <gospo@...adcom.com>,
        Sathya Perla <sathya.perla@...adcom.com>,
        vasundhara-v.volam@...adcom.com,
        Tariq Toukan <tariqt@...lanox.com>,
        Eran Ben Elisha <eranbe@...lanox.com>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        ASAP_Direct_Dev@...lanox.com
Subject: Re: [patch net-next RFC 00/12] devlink: introduce port flavours and
 common phys_port_name generation

On Tue, 17 Apr 2018 16:23:48 +0300, Or Gerlitz wrote:
> On Thu, Mar 22, 2018 at 1:55 PM, Jiri Pirko <jiri@...nulli.us> 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:  
> 
> J/J (Jiri/Jakub) --
> 
> re "2 physical ports, 1 pf, and 4 vfs" --- does NFP exposes one PF for
> both physical ports?

Yes there are multiple PCIe PFs on the card, but the basic CX card just
uses one for all uplinks (like mlx4).

> FWIW note that in mlx5 and AFAIK any other device except for mlx4 (...)
> folks have FPP (Function Per Port) scheme.
> 
> [..]
> 
> > 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.  
> 
> What is the purpose/role in getting dev link ports here? is it such
> that @ the end
> of the day the driver would do a devlink_port_get_phys_port_name() call in their
> get phys port name ndo? or we buy more advantages out of doing so?

IMHO having way to get all netdevs and the netdev type from devlink is
quite user friendly.  As of today we also use the devlink ports for port
splitting on 40/100G parts.  Hopefully more functionality migrates over
from ethtool over time.