netdev - Re: Changing devlink port flavor dynamically for DSA

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200406114233.GD510003@t480s.localdomain>
Date:   Mon, 6 Apr 2020 11:42:33 -0400
From:   Vivien Didelot <vivien.didelot@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     netdev <netdev@...r.kernel.org>, Andrew Lunn <andrew@...n.ch>,
        Vladimir Oltean <olteanv@...il.com>,
        Ido Schimmel <idosch@...sch.org>,
        Jiri Pirko <jiri@...nulli.us>, Jakub Kicinski <kuba@...nel.org>
Subject: Re: Changing devlink port flavor dynamically for DSA

On Sun, 5 Apr 2020 13:42:29 -0700, Florian Fainelli <f.fainelli@...il.com> wrote:
> Hi all,
> 
> On a BCM7278 system, we have two ports of the switch: 5 and 8, that
> connect to separate Ethernet MACs that the host/CPU can control. In
> premise they are both interchangeable because the switch supports
> configuring the management port to be either 5 or 8 and the Ethernet
> MACs are two identical instances.
> 
> The Ethernet MACs are scheduled differently across the memory controller
> (they have different bandwidth and priority allocations) so it is
> desirable to select an Ethernet MAC capable of sustaining bandwidth and
> latency for host networking. Our current (in the downstream kernel) use
> case is to expose port 5 solely as a control end-point to the user and
> leave it to the user how they wish to use the Ethernet MAC behind port
> 5. Some customers use it to bridge Wi-Fi traffic, some simply keep it
> disabled. Port 5 of that switch does not make use of Broadcom tags in
> that case, since ARL-based forwarding works just fine.
> 
> The current Device Tree representation that we have for that system
> makes it possible for either port to be elected as the CPU port from a
> DSA perspective as they both have an "ethernet" phandle property that
> points to the appropriate Ethernet MAC node, because of that the DSA
> framework treats them as CPU ports.
> 
> My current line of thinking is to permit a port to be configured as
> either "cpu" or "user" flavor and do that through devlink. This can
> create some challenges but hopefully this also paves the way for finally
> supporting "multi-CPU port" configurations. I am thinking something like
> this would be how I would like it to be configured:
> 
> # First configure port 8 as the new CPU port
> devlink port set pci/0000:01:00.0/8 type cpu
> # Now unmap port 5 from being a CPU port
> devlink port set pci/0000:01:00.0/1 type eth
> 
> and this would do a simple "swap" of all user ports being now associated
> with port 8, and no longer with port 5, thus permitting port 5 from
> becoming a standard user port. Or maybe, we need to do this as an atomic
> operation in order to avoid a switch being configured with no CPU port
> anymore, so something like this instead:
> 
> devlink port set pci/0000:01:00.0/5 type eth mgmt pci/0000:01:00.0/8
> 
> The latter could also be used to define groups of ports within a switch
> that has multiple CPU ports, e.g.:
> 
> # Ports 1 through 4 "bound" to CPU port 5:
> 
> for i in $(seq 0 3)
> do
> 	devlink port set pci/0000:01:00.0/$i type eth mgmt pci/0000:01:00.0/5
> done
> 
> # Ports 7 bound to CPU port 8:
> 
> devlink port set pci/0000:01:00.0/1 type eth mgmt pci/0000:01:00.0/8
> 
> Let me know what you think!

>From the DSA perspective, this would just be a devlink callback translated
to a ds->ops callback implemented by the driver to validate the different
types supported by a target port as well as switching between them at runtime.

I like this idea actually.


Thanks,

Vivien