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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 2 Mar 2019 11:13:37 +0100
From:   Jiri Pirko <jiri@...nulli.us>
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.

Thanks!