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

From: Christian Marangi <[email-masked]>
Date: Fri, 2 Sep 2022 20:44:37 +0200

On Tue, Aug 30, 2022 at 10:59:23PM +0300, Vladimir Oltean wrote:
> Those who have been following part 1:
> https://patchwork.kernel.org/project/netdevbpf/cover/[email-masked]/
> part 2:
> https://patchwork.kernel.org/project/netdevbpf/cover/[email-masked]/
> and part 3:
> https://patchwork.kernel.org/project/netdevbpf/cover/[email-masked]/
> 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/[email-masked]/

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...)

> 
> Vladimir Oltean (9):
>   net: introduce iterators over synced hw addresses
>   net: dsa: introduce dsa_port_get_master()
>   net: dsa: allow the DSA master to be seen and changed through
>     rtnetlink
>   net: dsa: don't keep track of admin/oper state on LAG DSA masters
>   net: dsa: suppress appending ethtool stats to LAG DSA masters
>   net: dsa: suppress device links to LAG DSA masters
>   net: dsa: allow masters to join a LAG
>   docs: net: dsa: update information about multiple CPU ports
>   net: dsa: felix: add support for changing DSA master
> 
>  .../networking/dsa/configuration.rst          |  84 +++++
>  Documentation/networking/dsa/dsa.rst          |  38 ++-
>  drivers/net/dsa/bcm_sf2.c                     |   4 +-
>  drivers/net/dsa/bcm_sf2_cfp.c                 |   4 +-
>  drivers/net/dsa/lan9303-core.c                |   4 +-
>  drivers/net/dsa/ocelot/felix.c                | 117 ++++++-
>  drivers/net/dsa/ocelot/felix.h                |   3 +
>  .../net/ethernet/mediatek/mtk_ppe_offload.c   |   2 +-
>  drivers/net/ethernet/mscc/ocelot.c            |   3 +-
>  include/linux/netdevice.h                     |   6 +
>  include/net/dsa.h                             |  19 ++
>  include/soc/mscc/ocelot.h                     |   1 +
>  include/uapi/linux/if_link.h                  |  10 +
>  net/dsa/Makefile                              |  10 +-
>  net/dsa/dsa.c                                 |   9 +
>  net/dsa/dsa2.c                                |  34 ++-
>  net/dsa/dsa_priv.h                            |  17 +-
>  net/dsa/master.c                              |  82 ++++-
>  net/dsa/netlink.c                             |  62 ++++
>  net/dsa/port.c                                | 159 +++++++++-
>  net/dsa/slave.c                               | 288 +++++++++++++++++-
>  net/dsa/switch.c                              |  22 +-
>  net/dsa/tag_8021q.c                           |   4 +-
>  23 files changed, 924 insertions(+), 58 deletions(-)
>  create mode 100644 net/dsa/netlink.c
> 
> -- 
> 2.34.1
> 

-- 
	Ansuel