Message-ID: <20220922180051.qo6swrvz2gqwgtlp@skbuf>
Date:   Thu, 22 Sep 2022 18:00:52 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     Andrew Lunn <andrew@...n.ch>,
        Stephen Hemminger <stephen@...workplumber.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        David Ahern <dsahern@...nel.org>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [PATCH v2 iproute2-next] ip link: add sub-command to view and
 change DSA master

On Thu, Sep 22, 2022 at 06:24:05AM -0700, Jakub Kicinski wrote:
> On Thu, 22 Sep 2022 03:30:43 +0200 Andrew Lunn wrote:
> > Looking at these, none really fit the concept of what the master
> > interface is.
> > 
> > slave is also used quite a lot within DSA, but we can probably use
> > user in place of that, it is already somewhat used as a synonym within
> > DSA terminology.
> > 
> > Do you have any more recommendations for something which pairs with
> > user. 
> 
> cpu-ifc? via?

It looks like I'll have to re-evaluate my path of minimal effort to make
progress with this.

I don't like cpu-ifc because it isn't sufficiently distinguished from
cpu port, which is the switch side interface that is connected to the
master. "The CPU interface connects to the CPU port, of course".

As for via, I didn't even know that this had a serious use in English as
a noun, other than the very specific term for PCB design. I find it
pretty hard to use in speech: "the via interface does this or that".

Going back to some of the suggestions Florian proposed:
https://patchwork.kernel.org/project/netdevbpf/patch/20220904190025.813574-1-vladimir.oltean@nxp.com/#24999435

| How about "conduit" or "mgmt_port" or some variant in the same lexicon?

I think "mgmt_port" really doesn't do a great job of distinguishing
itself from something that could belong to the switch itself either?

"Conduit" might be a better form of "via". I don't have a huge problem
with it, except that
(a) it's not a very conventional software term
(b) in Romanian, "conduit" means "conductă", and "conduct" means "conduită".
    Note that this probably shouldn't matter, but since we're having
    this discussion due to personal feelings, I thought I'd mention that
    to me, it requires that much more brain power ;)

I also keep thinking about "host controller", abbreviated to "HC", which
has the same connotation as in USB (xHCI). But I'm afraid this might get
confused with the SPI/I2C/MDIO controller that gets used for the
register access. Maybe host Ethernet controller, abbreviated "HEC"?
But a bonding interface can also be a DSA master, is it proper to call
that a HEC?

Another property that the name should have is that it should be well
suited for recursive use, meaning that a switch has a DSA master, but
that interface is itself a switch port which has a DSA master of its
own, and so on. Perhaps the "host controller" name is too suggestive of
just the bottom-most host network interface, rather than being able to
be nested?

There's also the option to use the good old fashioned word "parent".
I can't find too many counter arguments against it, except one which
Jakub has also expressed somewhere else, which is that the relationship
between a user port and its parent is actually reversed when it comes to
the netdev adjacency lists. The user ports are the upper interfaces of
the parent.

But I don't know if that is a very good argument. It's pretty hard to
clearly say if the DSA master is "on top of" or "beneath" switch ports.
In Documentation/networking/dsa/dsa.rst, we have this picture which
shows the stacking. I'd say in software, the DSA master is at the bottom
(a lower interface), while in hardware, it is at the top (the parent of
a series of attached switches).

                Unaware application
              opens and binds socket
                       |  ^
                       |  |
           +-----------v--|--------------------+
           |+------+ +------+ +------+ +------+|
           || swp0 | | swp1 | | swp2 | | swp3 ||
           |+------+-+------+-+------+-+------+|
           |          DSA switch driver        |
           +-----------------------------------+
                         |        ^
            Tag added by |        | Tag consumed by
           switch driver |        | switch driver
                         v        |
           +-----------------------------------+
           | Unmodified host interface driver  | Software
   --------+-----------------------------------+------------
           |       Host interface (eth0)       | Hardware
           +-----------------------------------+
                         |        ^
         Tag consumed by |        | Tag added by
         switch hardware |        | switch hardware
                         v        |
           +-----------------------------------+
           |               Switch              |
           |+------+ +------+ +------+ +------+|
           || swp0 | | swp1 | | swp2 | | swp3 ||
           ++------+-+------+-+------+-+------++

Powered by blists - more mailing lists