New Zephyr DSA Architecuture

[JiafeiPan]

What is DSA and why need DSA

Currently we have different networking switch solutions, some SoC provides onchip networking switch, such as i,MX943 and ls1028 provides the onchip tsn switch, and for the SoC has no on-chip switch, they could connect external networking switch chip for example SJA1105. Another solution from NXP is Heterogeneous Multi-SoC Architecture, it use MPU plus a MCU with networking switch, for example, use i.MX93 together with RT1180, it provides more IO ports compared with using SJA1105 such switch chip. And for each solution, we could cascade more switch chips to build up a switch tree.

So we can find so many switch ports in single or multiple switch chips, and each vendors or each SoC may define different switch protocol and private design.

Distributed Switch Architecture (DSA) is a framework originally designed in Linux networking, it provides a standardized or unified way to configure and control these switches ports from Linux, treating them as part of the overall network stack. The advantage of DSA is to map each networking switch ports to be a networking interface, so that it can leverage unified configuration tools to configure and manage the hardware switch tree, and unified socket API to receive or transmit frames for both switch ports and regular networking interface.

Problems

Currently a simple DSA architecture is provided in Zephyr, it only provides a single common driver: subsys/net/l2/ethernet/dsa/dsa.c to provides few DSA common APIs, and some related code( for exmaple tag protocol) is still in vendors device driver, and verndors device driver is still mixing endpoint port driver and switch ports driver, the limitation is still exiting in device tree binding, no unified dts binding to build switch tree. Compared with Linux DSA, currently it is difficult to build flexible networking switch setup, for example combine bridge and vlan protocol with DSA archtecuture.

New Zephyr DSA Architecture Proposal

The new Zephyr DSA architecutre as follows diagram:

And the frame RX TX flow will be like the following diagram:

Update for the new DSA Architecture

• New DSA Core in zephyr/subsys/net/l2/ethernet/dsa

dsa_core.c: APIs for DSA tree, on top of master ports and slave ports, according to dts to build DSA tree, Common APIs for DSA configurations.
dsa_switch.c: APIs for switch object to maintain the configuration for the single switch
master_port.c: APIs for maintain master ports
slave_port.c: APIs for maintaining slave ports
dsa_bridge.c: APIs to build bridge for networking switch
dsa_tag.c, dsa_tag_sja1105 … : TAG protocol for common DSA TAG and verdor specific TAG manipulations.

• Common Networking Stack update

Update bridge stack to add DSA offload support: subsys/net/l2/ethernet/bridge.c
Update vlan stack to add DSA offload support: subsys/net/l2/ethernet/vlan.c

• DSA configure tools support

Add DSA support in common network shell commands: zephyr/subsys/net/lib/shell
Add DSA bridge support in bridge shell: zephyr/subsys/net/l2/ethernet/bridge_shell.c
DSA Common dts binding in zephyr/dts/bindings/dsa
dsa.yaml: define common dsa dts binding for building DSA tree.

• DSA Switch Driver Update

Define Vender specified DSA operations APIs to cover: brindge ops, vlan ops, fdb ops, timestamp ops, …
Update frames RX/TX flow according to new design.

Plan

• Current DSA Code clean up

Yangbo submitted a PR to initial and clean up the DSA Core code and simple document update:
#87045

• Enhanced DSA Core

Provide enhanced DSA Core code to buildup the DSA tree, enhanced DSA TAG protocol, enhanced bridge and vlan protocol

• Configuration tools

More and unified networking shell commands for the new DSA architecutue.

[dleach02]

Attention @lmajewski @jukkar @rlubos

[lmajewski]

@JiafeiPan - thank you for sharing the detailed plan for DSA extension.

I would like to point out some problems / issues to be aware of regarding your work:

1. Please keep in mind that this DSA code shall be modular - as for example the work related to ip_k66f was aiming to be small and simple, as the target application is to have really resource constrained uC, which configures switch IC (and utilizes as much of its HW as possible) and only perform some management tasks. Hence the code shall be modular and produce small footprint when required.
2. I think that keeping DTS description similar to one from Linux kernel is a way to go. In that way we can reuse it from switch ICs which are already supported in Linux.
3. The code structure (i.e. files naming, code division) shall be similar to Linux DSA driver (unfortunately we cannot port it directly as licenses differ).
4. The management tools also shall be modular - and easily disabled.
5. Files shall be separated from LEGACY DSA driver - finally current boards would be moved to the new driver.

My biggest concern is that DSA driver for Zephyr would be too large to use it on a tiny uC (as this is the main use case for now).

[JiafeiPan]

Hi, @lmajewski, thanks for your comments/suggestions.

1. For your first and fourth comments, I totally agree with you, we will define each feature to be modular, including each management tools, so that we can make it works on small footprint, and keep in mind, we should build a light weight DSA in Zephyr.
2. for your second comment, also total agree with you, and except dts description, we also want to use the same user experience for management tools with Linux, it means some tools' parameters will align with Linux, so that it is easy to port the networking configuration from Linux to Zephyr.
3. for your third comment, we could use the similar structure but we won't copy directly, and we also want some improvement from Linux implement, for example we want to introduce "switch" object to make it easy to configure some switch level parameters.
4. for your fifth, yes, we will use separated driver file for new DSA driver, in development period, we will keep both legacy and new driver existing simultaneously, and then remove legacy driver and port all current board to new driver when we think new DSA driver stable enough.

and in order to make DSA driver to be light enough, maybe we could provide an approach to statically configure networking switch by though DTS or some specified configure file, so that no any runtime management tools is needed for small footprint device.