Linux DSA网络架构详解：从零理解分布式交换机驱动的实现原理（1）

如果你曾经拆开过一台家用无线路由器、或者捣鼓过一块嵌入式开发板，可能会注意到一个有趣的现象：那些标着“LAN1”、“LAN2”、“WAN”的以太网口，背后往往连着一颗独立的交换机芯片。这颗芯片负责在几个物理端口之间高速转发数据包，而主处理器（CPU）通常只通过一个“CPU端口”与它相连。在传统的Linux网络驱动模型里，每个物理网口（ETH0、ETH1）都对应一个独立的网络接口，由内核直接管理。但面对这种“一个CPU管一堆交换机端口”的硬件现实，传统模型就显得有些笨拙和低效了。

于是，DSA（Distributed Switch Architecture，分布式交换机架构）应运而生。它不是为了取代传统的网络驱动，而是为这种特殊的硬件拓扑量身打造的一套软件抽象。简单来说，DSA的目标是让连接到交换机芯片上的每一个物理端口，在Linux系统中都能像一个独立的、标准的网络接口（比如LAN0、LAN1、WAN）那样被识别、配置和管理，同时又能充分利用交换机芯片的硬件转发能力，让数据包在端口间“直通”，无需CPU干预。

理解DSA，不仅仅是多学一个内核子系统。它代表了一种更贴近现代网络硬件（尤其是嵌入式、路由器和网络设备）的软件设计思想。对于从事网络设备开发、嵌入式Linux系统定制、或者单纯对Linux网络栈有深度好奇的开发者而言，摸清DSA的脉络，就像拿到了一把打开复杂网络硬件管理大门的钥匙。接下来，我们将抛开晦涩的术语堆砌，从实际需求出发，一步步拆解DSA的核心组件、数据流和驱动实现，看看Linux是如何优雅地“驯服”这些分布式交换芯片的。

1. 传统驱动与DSA驱动：思维模式的根本转变

在深入DSA内部之前，必须先搞清楚它要解决什么问题。让我们从一个具体的硬件场景开始：一块集成了5端口千兆交换芯片的嵌入式主板。CPU通过一个内部GMAC（千兆媒体访问控制器）连接到交换芯片的某个特定端口（通常标记为CPU端口或上行端口），而另外4个端口则作为LAN口引出。

1.1 传统模型的困境

在传统驱动模型下，开发者可能会面临两种选择：

1）为每个物理端口编写独立驱动

这意味着你需要为交换芯片的5个端口（包括CPU端口）都实现一个完整的net_device。数据包从LAN1到LAN2的转发，即便交换芯片硬件可以完成，也可能需要先上行到CPU的eth0（对应CPU端口），经内核网络栈处理，再下行到eth1（对应LAN2）。这造成了不必要的CPU负载和延迟。

2）编写一个“超级”驱动管理所有端口

驱动创建一个主接口（如eth0），然后通过私有API或ethtool来配置内部的交换逻辑。用户空间工具（如ip link,bridge）无法直接感知到LAN1、LAN2作为独立接口存在，管理起来非常不便，且与标准的Linux网络工具链脱节。

这两种方式要么性能低下，要么破坏了Linux网络配置的统一性。DSA的巧妙之处在于，它引入了一个中间层，既向用户空间呈现了独立的网络接口，又在底层驱动中实现了高效的硬件转发。

1.2 DSA模型的抽象视图

DSA重新定义了软件与这类硬件的关系。它将整个交换芯片抽象为一个DSA Switch，将CPU连接的那个端口称为Master或CPU端口，将其它用户可用的物理端口称为Slave端口或用户端口。

• 用户视角

每个Slave端口（如lan0、lan1、wan）都是一个完全标准的Linux网络接口。你可以用ip link set lan0 up启用它，用bridge命令将它加入网桥，用tc给它配置流量控制，一切操作与对待eth0无异。

• 内核视角

Master接口（例如eth0）承载了所有Slave端口与内核网络栈之间的控制流和部分数据流。但关键的数据转发路径、特别是Slave端口之间的数据交换，被尽可能地“卸载”到了交换芯片硬件中。

提示：你可以把Master接口想象成交换芯片的管理通道和数据上行总站，而Slave接口则是面向各个房间（用户空间应用）的独立门户。管理指令通过总站下达，但房间之间的物品（数据包）传递，如果目的地明确，可以直接在建筑内部（交换芯片）完成，无需每次都跑到总站绕一圈。

这种架构带来了几个立竿见影的好处：

• 管理标准化

无缝集成到iproute2、systemd-networkd、NetworkManager等现有生态。

• 性能优化

同交换机芯片下的端口间转发由硬件完成，线速无阻塞。

• 功能透明

VLAN、网桥、STP等二层功能可以借助硬件加速，同时保持对上层配置的透明。

为了更清晰地对比两种模型的关键差异，请看下表：

2. DSA核心框架剖析：dsa_core与关键数据结构

理解了“为什么需要DSA”之后，我们进入内核源码的net/dsa/目录，看看这套框架是如何搭建起来的。DSA的实现可以看作是一系列精心设计的数据结构和协作模块的集合。

2.1 核心文件与模块

根据提供的原始资料，net/dsa/Makefile揭示了核心构成：

# SPDX-License-Identifier: GPL-2.0 # the core obj-$(CONFIG_NET_DSA) += dsa_core.o dsa_core-y += dsa.o dsa2.o master.o port.o slave.o switch.o # tagging formats obj-$(CONFIG_NET_DSA_TAG_8021Q) += tag_8021q.o obj-$(CONFIG_NET_DSA_TAG_DSA) += tag_dsa.o # ... 其他 tagging 模块

• dsa_core：这是DSA框架的心脏，由dsa.o、dsa2.o、master.o、port.o、slave.o、switch.o等多个文件编译而成。它提供了注册、管理交换机，创建Slave接口，以及在内核网络栈和具体交换机驱动之间路由数据包和控制命令的通用逻辑。
• tag_*.o：这些是标签（Tagging）协议模块。它们是DSA数据平面实现的关键，我们会在下一章详细讨论。简单来说，标签机制解决了“如何让Master接口识别一个数据包是属于哪个Slave端口”这个核心问题。

2.2 理解struct dsa_switch与struct dsa_switch_ops

对于每一个具体的交换芯片，驱动开发者需要实现一个struct dsa_switch实例。这个结构体代表了一个被DSA框架管理的物理或逻辑交换设备。但驱动代码填充的并非dsa_switch本身的所有字段，更多的是提供一个操作集（Operations Set）—— 也就是struct dsa_switch_ops。

原始资料中MT7530驱动的例子非常典型：

static const struct dsa_switch_ops mt7530_switch_ops = { .get_tag_protocol = mtk_get_tag_protocol, .setup = mt7530_setup, .port_enable = mt7530_port_enable, .port_disable = mt7530_port_disable, .port_stp_state_set = mt7530_stp_state_set, .port_bridge_join = mt7530_port_bridge_join, .port_bridge_leave = mt7530_port_bridge_leave, .port_vlan_add = mt7530_port_vlan_add, .port_vlan_del = mt7530_port_vlan_del, .phylink_mac_config = mt7530_phylink_mac_config, .phylink_mac_link_up = mt7530_phylink_mac_link_up, // ... 更多操作 };

这个结构体定义了一组回调函数（callbacks），DSA核心框架会在适当的时机调用它们，从而将通用的网络配置命令“翻译”成针对特定交换芯片的寄存器读写操作。例如：

• 当用户执行ip link set lan0 up时，DSA核心最终会调用.port_enable。
• 当将lan0和lan1加入一个网桥时，会调用.port_bridge_join。
• 当需要配置端口的VLAN成员关系时，会调用.port_vlan_add。

struct dsa_switch则是一个更庞大的结构，它包含了交换机的状态信息、端口数组、指向dsa_switch_ops的指针、私有数据指针等。驱动在probe函数中分配并初始化这个结构，然后通过dsa_register_switch()将其注册到DSA核心。

2.3 驱动注册的生命周期

一个DSA交换机驱动的初始化流程，清晰地展示了框架与驱动的协作关系：

1）模块初始化

驱动使用mdio_module_driver()宏（针对MDIO总线）或类似机制注册为一个标准的内核设备驱动。

2）设备探测（Probe）

当设备树（Device Tree）或ACPI匹配到驱动后，内核调用驱动的probe函数（如mt7530_probe）。

3）分配与初始化

在probe中，驱动分配struct dsa_switch内存，填充必要信息（如端口数量、支持的标签协议），并将dsa_switch_ops操作集赋值给ds->ops。

4）注册交换机

调用dsa_register_switch(priv->ds)。这是关键一步，DSA核心会在此函数中：
a）验证驱动提供的信息；
b）为每个Slave端口创建对应的net_device（Slave接口）；
c）将这些Slave接口与Master接口关联起来；
d）初始化内部的数据结构和状态机。

5）运行与交互

注册成功后，用户空间即可看到并使用lan0等接口。所有网络操作通过DSA核心路由，并转化为对dsa_switch_ops中具体函数的调用。

6）设备移除

在驱动remove函数中调用dsa_unregister_switch()，DSA核心负责清理所有创建的接口和资源。

这个流程将硬件特定的操作（dsa_switch_ops）与通用的管理框架（dsa_core）完美解耦。驱动开发者只需关注“如何操作我的芯片”，而无需操心如何创建网络接口、如何与netlink通信等复杂的内核基础设施。

更多内容请看下回。