Re: [RFC PATCH net-next] docs: net: add an explanation of VF (and other) Representors

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 10 Aug 2022 17:02:33 +0100 Edward Cree wrote:
> On 09/08/2022 04:41, Jakub Kicinski wrote:
> >> Maybe a bad word choice.  I'm referring to whichever PF (which likely
> >>  also has an ordinary netdevice) has administrative rights over the NIC /
> >>  internal switch at a firmware level.  Other names I've seen tossed
> >>  around include "primary PF", "admin PF".  
> > 
> > I believe someone (mellanox?) used the term eswitch manager.
> > I'd use "host PF", somehow that makes most sense to me.  
> 
> Not sure about that, I've seen "host" used as antonym of "SoC", so
>  if the device is configured with the SoC as the admin this could
>  confuse people.

In the literal definition of the word "host" it is the entity which
"owns the place".

> I think whatever term we settle on, this document might need to
>  have a 'Definitions' section to make it clear :S

Ack, to perhaps clarify my concern further, I've seen the term
"management PF" refer to a PF which is not a netdev PF, it only
performs management functions. Which I don't believe is what we
are describing here. So a perfect term would describe the privilege
not the function (as the primary function of such PF should still
networking).

> >> Yes, that's where I got this terminology from.
> >> "the" PCIe controller here is the one on which the mgmt PF lives.  For
> >>  instance you might have a NIC where you run OVS on a SoC inside the
> >>  chip, that has its own PCIe controller including a PF it uses to drive
> >>  the hardware v-switch (so it can offload OVS rules), in addition to
> >>  the PCIe controller that exposes PFs & VFs to the host you plug it
> >>  into through the physical PCIe socket / edge connector.
> >> In that case this bullet would refer to any additional PFs the SoC has
> >>  besides the management one...  
> > 
> > IMO the model where there's a overall controller for the entire device
> > is also a mellanox limitation, due to lack of support for nested
> > switches  
> Instead of "the PCIe controller" I should probably say "the local PCIe
>  controller", since that's the wording the devlink-port doc uses.

SG!

> > "TX queue attached to" made me think of a netdev Tx queue with a qdisc
> > rather than just a HW queue. No better ideas tho.  
> 
> Would adding the word "hardware" before "TX queue" help?  Have to
>  admit the netdev-queue interpretation hadn't occurred to me.

It would!

> >> (And it looks like the core uses `c<N>` for my `if<N>` that you were
> >>  so horrified by.  Devlink-port documentation doesn't make it super
> >>  clear whether controller 0 is "the controller that's in charge" or
> >>  "the controller from which we're viewing things", though I think in
> >>  practice it comes to the same thing.)  
> > 
> > I think we had a bit. Perhaps @external? The controller which doesn't
> > have @external == true should be the local one IIRC. And by extension
> > presumably in charge.  
> 
> Yes, and that should work fine per se.  It's just not reflected in the
>  phys_port_name string in any way, so legacy userland that relies on
>  that won't have that piece of info (but it never did) and probably
>  assumes that c0 is local.

Ack, we could check the archive but I think that's indeed the case.