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.
