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

Parav Pandit
2019-03-04T05:12:21Z

> -----Original Message-----
> From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
> Behalf Of Jiri Pirko
> Sent: Saturday, March 2, 2019 4:14 AM
> To: Jakub Kicinski <jakub.kicinski@netronome.com>
> Cc: davem@davemloft.net; netdev@vger.kernel.org; oss-
> drivers@netronome.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@netronome.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.