Documentation/networking/dsa/dsa.rst

Source file repositories/reference/linux-study-clean/Documentation/networking/dsa/dsa.rst

File Facts

System
Linux kernel
Corpus path
Documentation/networking/dsa/dsa.rst
Extension
.rst
Size
60647 bytes
Lines
1136
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

============
Architecture
============

This document describes the **Distributed Switch Architecture (DSA)** subsystem
design principles, limitations, interactions with other subsystems, and how to
develop drivers for this subsystem as well as a TODO for developers interested
in joining the effort.

Design principles
=================

The Distributed Switch Architecture subsystem was primarily designed to
support Marvell Ethernet switches (MV88E6xxx, a.k.a. Link Street product
line) using Linux, but has since evolved to support other vendors as well.

The original philosophy behind this design was to be able to use unmodified
Linux tools such as bridge, iproute2, ifconfig to work transparently whether
they configured/queried a switch port network device or a regular network
device.

An Ethernet switch typically comprises multiple front-panel ports and one
or more CPU or management ports. The DSA subsystem currently relies on the
presence of a management port connected to an Ethernet controller capable of
receiving Ethernet frames from the switch. This is a very common setup for all
kinds of Ethernet switches found in Small Home and Office products: routers,
gateways, or even top-of-rack switches. This host Ethernet controller will
be later referred to as "conduit" and "cpu" in DSA terminology and code.

The D in DSA stands for Distributed, because the subsystem has been designed
with the ability to configure and manage cascaded switches on top of each other
using upstream and downstream Ethernet links between switches. These specific
ports are referred to as "dsa" ports in DSA terminology and code. A collection
of multiple switches connected to each other is called a "switch tree".

For each front-panel port, DSA creates specialized network devices which are
used as controlling and data-flowing endpoints for use by the Linux networking
stack. These specialized network interfaces are referred to as "user" network
interfaces in DSA terminology and code.

The ideal case for using DSA is when an Ethernet switch supports a "switch tag"
which is a hardware feature making the switch insert a specific tag for each
Ethernet frame it receives to/from specific ports to help the management
interface figure out:

- what port is this frame coming from
- what was the reason why this frame got forwarded
- how to send CPU originated traffic to specific ports

The subsystem does support switches not capable of inserting/stripping tags, but
the features might be slightly limited in that case (traffic separation relies
on Port-based VLAN IDs).

Note that DSA does not currently create network interfaces for the "cpu" and
"dsa" ports because:

- the "cpu" port is the Ethernet switch facing side of the management
  controller, and as such, would create a duplication of feature, since you
  would get two interfaces for the same conduit: conduit netdev, and "cpu" netdev

- the "dsa" port(s) are just conduits between two or more switches, and as such
  cannot really be used as proper network interfaces either, only the
  downstream, or the top-most upstream interface makes sense with that model

NB: for the past 15 years, the DSA subsystem had been making use of the terms
"master" (rather than "conduit") and "slave" (rather than "user"). These terms
have been removed from the DSA codebase and phased out of the uAPI.

Switch tagging protocols
------------------------

Annotation

Implementation Notes