netdev - RE: [PATCH net-next v2 0/7] devlink: expose PF and VF representors as ports

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: <VI1PR0501MB2271FF5E6EC67D1D1547D0D7D1710@VI1PR0501MB2271.eurprd05.prod.outlook.com>
Date:   Mon, 4 Mar 2019 05:12:12 +0000
From:   Parav Pandit <parav@...lanox.com>
To:     Jiri Pirko <jiri@...nulli.us>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "oss-drivers@...ronome.com" <oss-drivers@...ronome.com>
Subject: RE: [PATCH net-next v2 0/7] devlink: expose PF and VF representors as
 ports



> -----Original Message-----
> From: netdev-owner@...r.kernel.org <netdev-owner@...r.kernel.org> On
> Behalf Of Jiri Pirko
> Sent: Saturday, March 2, 2019 4:14 AM
> To: Jakub Kicinski <jakub.kicinski@...ronome.com>
> Cc: davem@...emloft.net; netdev@...r.kernel.org; oss-
> drivers@...ronome.com
> Subject: Re: [PATCH net-next v2 0/7] devlink: expose PF and VF representors
> as ports
> 
> Fri, Mar 01, 2019 at 07:04:46PM CET, jakub.kicinski@...ronome.com wrote:
> >Hi!
> >
> >This series is a long overdue follow up to Jiri's work on providing a
> >common .ndo_phys_port_name implementation based on devlink ports.
> >
> >First devlink port flavours for PF and VF ports are added, and
> >registered by the NFP. Port numbers and split info are reserved for
> >physical and DSA ports. For PCIe ports we add pf/vf identifiers.
> >Note that devices may have more than one PF, including multi host
> >scenarios where not all pfs are connected to the same host.
> >
> >The port_index is slightly tricky to figure out, we use a bit of math
> >to create unique IDs for ports.
> >
> >Next subports for PCIe ports are introduced. This is in case device has
> >more than one netdev on a physical function (e.g. multi port SmartNIC).
> >
> >With the above features in place we can remove the ndo_phys_port_name
> >implementation from the NFP and use the standard devlink one for port
> >netdevs.
> >
> >Last but not least a concept of peer netdevs is added. In multi-host
> >scenarios its currently not possible to figure out which PF is
> >associated with the local host. Peer device is "the other side of the
> >wire" for PCIe ports. In case of NFP we only link the PF netdevs, but
> >it should be possible to also link VF peers after VF driver probes, if
> >users request it.
> >
> >This is the conceptual image of devlink instances:
> >
> >                    HOST A             ||          HOST B
> >                                       ||
> >        PF A       | V | V | V | V     ||       PF B        | V | V | V
> >                   |*F |*F |*F |*F ... ||                   |*F |*F |*F
> >*port A0 |*port A1 | 0 | 1 | 2 | 3     ||*port B0 |*port B1 | 0 | 1 | 2
> >                                       ||
> >             PCI Express link          ||        PCI Express link
> >        \      \      \  |   |   |          |       |      /   /   /
> >         \      \      \ |   |   |          |       |     /   /   /
> >      /\  \______\______\'___|___|__________|_______'____/___/___/__
> /\
> >      ||  |+PF0s0|+PF0s1 |+VF0|+VF1| ...|   |+PF1s0|+PF1s1|+VF0|+VF1|   ||
> >  i   ||  |------ ------ ----- ---- ----|--- ------ ------ ---- ----|   ||   i
> >d n H ||  |               <<==========                              |   || d n H
> >e s O ||  |                            ==========>>                 |   || e s O
> >v t S ||  |                    SR-IOV e-switch                      |   || v t S
> >l a T ||  |               <<==========                              |   || l a T
> >i n   ||  |                            ==========>>                 |   || i n
> >n c A ||  |               ________ _________ ________               |   || n c B
> >k e   ||  |              |+Phys 0 |+Phys 1  |+Phys 2 |              |   || k e
> >      ||  \---------------------------------------------------------/   ||
> >      \/                      |        |         |                      \/
> >                              |        |         |
> >                                 ||         ||
> >                          MAC 0  ||  MAC 1  || MAC 2
> >                                 ||         ||
> >
> > '+' marks the devlink ports and port (-representor-) netdevs '*' marks
> > host netdevs (actual VF/PF netdev)
> 
> As I wrote in the reply to patch 4, I think we need to figure out if we want to
> model all entities that belong under specific devlink instance/pci address -
> which I prefer, or we want to have only eswitch ports there.
> 
> One way or another, I think that it is not good idea to merge this patchset
> this late, I would prefer to wait for next net-next opening...
> In the meantime we can sync and make this whole thing crystal clear, for
> everyone.
> 
Yes, please.
I replied in other thread, we should not bring peer port concept. It is convoluted.
We just need hostport and switchport representation (likely as port flavours) to configure each separately.
Whether a given devlink device is PF or VF is devlink devie attribute anyway.