On Wed, Aug 10, 2022 at 12:21 PM Edward Cree <ecree.xilinx@xxxxxxxxx> wrote: > > On 10/08/2022 18:58, Jakub Kicinski wrote: > > On Wed, 10 Aug 2022 17:02:33 +0100 Edward Cree wrote: > >> On 09/08/2022 04:41, Jakub Kicinski wrote: > >>> 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". > > Sure, but as an application of that, people talk about e.g. "host" > and "device" ends of a bus, DMA transfer, etc. As a result of which > "host" has come to mean "computer; server; the big rack-mounted box > you plug cards into". > A connotation which is unfortunate once a single device can live on > two separate PCIe hierarchies, connected to two computers each with > its own hostname, and the one which owns the device is the cluster > of embedded CPUs inside the card, rather than the big metal box. I agree that "host" isn't going to work as a multi-host capable device might end up having only one "host" that can actually handle the configuration of the switch for the entire device. So then you have different types of "host" interfaces. > >> 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. > > Yeah, I saw that interpretation as soon as you queried it. I agree > we probably can't use "management PF". One thing we may want to think about is looking more at "interfaces" rather than "devices" or "functions". Essentially a PF is a "Host Network Interface", a VF or sub-function would be a "Virtual Network Interface", and an external port would be an "External/Uplink Interface". Then we have a set of "interfaces" which would allow us to get away from confusing networking and PCI bus topology where we also have functions that are present on the device that may not expose networking interfaces and provide control only. In addition something like a VNI is more extensible so if we start getting into some other new virtualization option in the future we are not stuck having to go through and add yet more documentation to describe it all. > > So a perfect term would describe the privilege > > not the function (as the primary function of such PF should still > > networking). > > I'm probably gonna get shot for suggesting this, but how about > "master PF"? Usually with "master" you are talking about something like a bus. It also occurs to me that the use of PF is assuming a single PCIe function dedicated to performing this role. With sub-functions floating around I could easily see a PF getting partitioned to dedicate queues to handling switchdev operations while still allowing other networking to pass over the original network interface. Then the question is which one is the PF and which one is the subfunction. I'd be more a fan of sticking with the "interface" naming and describing what the interface would be used for. The first thought that comes to mind is to just refer to the configuration interface as a "NIC" since that would be the "Network Interface Controller", however I could see how that could easily be confusing since that is the PCI description for the device. Maybe something like a "Controller Interface", "CI", would make sense since it seems like OVS uses "Controller" to describe the instance that programs the flows, so we could use similar terminology.
