Re: [PATCH net-next 0/9] DSA changes for multiple CPU ports (part 4)

On Fri, 2 Sep 2022 20:44:37 +0200
Christian Marangi [off-list ref] wrote:

On Tue, Aug 30, 2022 at 10:59:23PM +0300, Vladimir Oltean wrote:

quoted

Those who have been following part 1:
https://patchwork.kernel.org/project/netdevbpf/cover/20220511095020.562461-1-vladimir.oltean@nxp.com/
part 2:
https://patchwork.kernel.org/project/netdevbpf/cover/20220521213743.2735445-1-vladimir.oltean@nxp.com/
and part 3:
https://patchwork.kernel.org/project/netdevbpf/cover/20220819174820.3585002-1-vladimir.oltean@nxp.com/
will know that I am trying to enable the second internal port pair from
the NXP LS1028A Felix switch for DSA-tagged traffic via "ocelot-8021q".

This series represents the final part of that effort. We have:

- the introduction of new UAPI in the form of IFLA_DSA_MASTER

- preparation for LAG DSA masters in terms of suppressing some
  operations for masters in the DSA core that simply don't make sense
  when those masters are a bonding/team interface

- handling all the net device events that occur between DSA and a
  LAG DSA master, including migration to a different DSA master when the
  current master joins a LAG, or the LAG gets destroyed

- updating documentation

- adding an implementation for NXP LS1028A, where things are insanely
  complicated due to hardware limitations. We have 2 tagging protocols:

  * the native "ocelot" protocol (NPI port mode). This does not support
    CPU ports in a LAG, and supports a single DSA master. The DSA master
    can be changed between eno2 (2.5G) and eno3 (1G), but all ports must
    be down during the changing process, and user ports assigned to the
    old DSA master will refuse to come up if the user requests that
    during a "transient" state.

  * the "ocelot-8021q" software-defined protocol, where the Ethernet
    ports connected to the CPU are not actually "god mode" ports as far
    as the hardware is concerned. So here, static assignment between
    user and CPU ports is possible by editing the PGID_SRC masks for
    the port-based forwarding matrix, and "CPU ports in a LAG" simply
    means "a LAG like any other".

The series was regression-tested on LS1028A using the local_termination.sh
kselftest, in most of the possible operating modes and tagging protocols.
I have not done a detailed performance evaluation yet, but using LAG, is
possible to exceed the termination bandwidth of a single CPU port in an
iperf3 test with multiple senders and multiple receivers.

There was a previous RFC posted, which contains most of these changes,
however it's so old by now that it's unlikely anyone of the reviewers
remembers it in detail. I've applied most of the feedback requested by
Florian and Ansuel there.
https://lore.kernel.org/netdev/20220523104256.3556016-1-olteanv@gmail.com/ (local)  

Hi,
I would love to test this but for me it's a bit problematic to use a
net-next kernel. I wonder if it's possible to backport the 4 part to
older kernel or other prereq are needed. (I know backporting the 4 part
will be crazy but it's something that has to be done anyway to actually
use this on OpenWrt where we currently use 5.10 and 5.15)

Would be good to know if the 4 part require other changes to dsa core to
make a LAG implementation working. (talking for 5.15 since backporting
this to 5.10 is a nono...)

Just use the newest kernel. Trust me, backporting new DSA changes to
5.15 is painful. And to 5.10 and earlier it is a literal hell.

:) Marek