Message-ID: <CAKgT0UdLFjxdxHTPb7c+Deih2Bciziz=gZxDYWUFsLNNetOFQg@mail.gmail.com>
Date:   Wed, 10 Aug 2022 15:58:54 -0700
From:   Alexander Duyck <alexander.duyck@...il.com>
To:     Edward Cree <ecree.xilinx@...il.com>
Cc:     Jakub Kicinski <kuba@...nel.org>, ecree@...inx.com,
        netdev@...r.kernel.org, davem@...emloft.net, pabeni@...hat.com,
        edumazet@...gle.com, corbet@....net, linux-doc@...r.kernel.org,
        linux-net-drivers@....com, Jacob Keller <jacob.e.keller@...el.com>,
        Jesse Brandeburg <jesse.brandeburg@...el.com>,
        Michael Chan <michael.chan@...adcom.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        Saeed Mahameed <saeed@...nel.org>,
        Jiri Pirko <jiri@...nulli.us>,
        Shannon Nelson <snelson@...sando.io>,
        Simon Horman <simon.horman@...igine.com>
Subject: Re: [RFC PATCH net-next] docs: net: add an explanation of VF (and
 other) Representors

On Wed, Aug 10, 2022 at 12:21 PM Edward Cree <ecree.xilinx@...il.com> 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.

Powered by blists - more mailing lists