📚 课程目录第2章数据面核心概念

2. 数据面核心概念

在交换芯片的数据面世界里，报文从端口进入、经过一系列处理、最终从某个端口送出，整个过程并不是“一个程序从头跑到尾”的软件逻辑，而是由硬件流水线按固定节拍推进的。理解数据面，最关键的是抓住四个概念：流水线（Pipeline）、表项（Table Entry）、匹配动作（Match-Action），以及把它们统一起来的报文处理抽象模型。这四个概念构成了从 Broadcom Trident、Tomahawk 到 Jericho 系列芯片都通用的思维框架。

流水线：数据面的“装配线”

流水线是数据面的骨架。报文进入芯片后，会依次经过若干个处理阶段（Stage），每个阶段在固定的时钟周期内完成一部分工作，然后把结果交给下一阶段。这种设计让芯片可以同时处理大量报文——当第 1 个报文在阶段 3 时，第 2 个报文可能正在阶段 2，第 3 个报文刚进入阶段 1，形成吞吐量远高于单报文串行处理的并行结构。

以典型的交换流水线为例，报文大致会经历：入端口解析（Parser）→ 入向处理（Ingress Pipeline，含多个 Stage）→ 流量管理/缓存（Traffic Manager）→ 出向处理（Egress Pipeline）→ 出端口编辑与发送（Editor/MMU）。解析器负责把报文的各层头部（以太、VLAN、IPv4/IPv6、TCP/UDP 等）拆解成内部字段；入向流水线根据这些字段查表、做转发决策、ACL 过滤、计数；流量管理负责排队、调度、丢弃；出向流水线再做一次基于出端口的处理；最后编辑阶段重写头部并发出。

需要强调的是，流水线的“阶段”是硬件资源，数量有限且固定。例如某代 Trident 芯片入向有若干 Stage，每个 Stage 能容纳的查表逻辑和动作数量都有上限。这直接决定了我们能下发多少条表项、能叠加多少层处理逻辑。工程上常说的“表项放不下”“Stage 不够用”，根源就在这里。

表项：流水线的“决策依据”

流水线本身只是通道，真正决定报文命运的是表项。表项是下发到芯片表（Table）中的一条条记录，通常由匹配键（Key）和动作（Action）两部分组成。匹配键定义了“什么样的报文会命中我”，动作定义了“命中后做什么”。

表项可以按匹配方式分类：精确匹配（Exact Match）要求键值完全一致，常用于 MAC 表、精确流表；最长前缀匹配（LPM）用于路由表，按掩码长度选最优；三元匹配（TCAM）支持掩码和通配，用于 ACL、策略路由。不同匹配方式对应不同的硬件资源和查找算法，也决定了表项容量与查找速度的权衡。

表项不是孤立存在的，它隶属于某张表，而表又被绑定到流水线的某个 Stage。因此一条表项能否生效，取决于：这张表是否被分配了 Stage、Stage 是否有足够空间、匹配键字段是否被解析器正确提取。工程排查中，“表项下发了但报文不命中”，往往要沿着这条链路逐段确认。

匹配动作：数据面的“执行单元”

匹配动作是数据面最核心的抽象。它的逻辑非常简洁：用报文字段去查表，命中则执行对应动作。动作的种类决定了数据面的能力边界，常见动作包括：

转发类：指定出端口、设置下一跳、修改目的 MAC。
编辑类：压入/弹出 VLAN、修改 TTL、重写 DSCP、封装隧道头。
控制类：丢弃、重定向到 CPU、镜像到监控口。
统计类：计数器累加、采样。
元数据类：设置内部优先级、标记、传递到后续 Stage。

匹配动作的威力在于可组合。一个报文可以在入向 Stage 1 命中 ACL 表做过滤，在 Stage 2 命中路由表决定下一跳，在 Stage 3 命中 QoS 表设置优先级，出向再命中一张表做重写。每一层都是独立的“匹配—动作”，层层叠加，最终形成完整的转发行为。这种“分阶段、可组合”的模型，正是可编程交换芯片灵活性的来源。

报文处理抽象模型：把三者串起来

把流水线、表项、匹配动作放在一起，就得到数据面的抽象模型：报文 = 一组字段的集合；处理 = 在流水线的每个阶段，用字段子集去匹配表项，命中后执行动作，动作可能修改字段或产生元数据，供后续阶段使用。这个模型可以用下面的关系图表示。

这个模型有一个非常重要的工程含义：数据面的行为完全由“表项内容”决定，而不是由芯片固化的逻辑决定。同一颗芯片，下发不同的表项集合，就能表现为二层交换机、三层路由器、ACL 防火墙或隧道网关。这也是 SDN 和可编程数据面能够成立的基础。

一个具体的匹配动作示例

假设我们要实现“禁止源 IP 为 10.1.1.5 的主机访问 192.168.1.0/24，其余流量正常转发”。在抽象模型里，这可以拆成两条表项：

表：Ingress ACL（Stage 1，TCAM 匹配）
表项1：
  Key   : src_ip = 10.1.1.5/32, dst_ip = 192.168.1.0/24
  Action: drop, counter++

表项2（默认）：
  Key   : any
  Action: permit, goto Stage 2

表：Ingress Route（Stage 2，LPM 匹配）
表项：
  Key   : dst_ip = 192.168.1.0/24
  Action: set nexthop = 00:11:22:33:44:55, out_port = 3

报文进入后，Stage 1 先做 TCAM 匹配：若命中表项 1，直接丢弃并计数；否则命中默认表项放行，进入 Stage 2 做 LPM 路由查找，命中后设置下一跳和出端口。整个过程清晰体现了“分阶段匹配、逐层动作”的抽象模型。工程上验证时，可以分别查看两张表的命中计数：如果 ACL 计数不增长，说明报文没到 Stage 1 或匹配键写错；如果路由表命中但报文没发出，则要检查出端口状态和下一跳 MAC 是否正确。

理解数据面抽象模型的一个实用方法：把每个 Stage 想象成一个“if-else 判断块”，表项就是判断条件，动作就是判断块里的执行语句。多个 Stage 串联，就等价于多层嵌套的判断逻辑。区别只在于，这些判断是硬件并行执行的，且条件数量受 Stage 容量限制。

抽象模型与真实芯片的对应

在 Broadcom 芯片的 SDK（如 OpenNSL、SAI、OF-DPA）中，上述抽象会被映射为具体的 API 对象：表对应 table，表项对应 entry，匹配键对应 key fields，动作对应 action。不同芯片代际的 Stage 数量、每 Stage 表容量、支持的匹配类型和动作集合不同，但“流水线—表项—匹配动作”的框架是一致的。掌握这个框架后，面对任何一款交换芯片，都能快速定位“这条转发逻辑应该放在哪个阶段、用哪张表、配什么键和动作”。

最后要提醒的是，抽象模型虽然简洁，但真实数据面还有两个不可忽视的约束：资源约束（Stage、表项、TCAM 深度、计数器数量都是有限的）和顺序约束（动作的执行顺序、字段修改的可见性在阶段之间有严格定义）。工程实践中，很多问题不是“逻辑写错了”，而是“资源放不下”或“顺序搞反了”。理解抽象模型，正是为了在遇到这些约束时，知道该从哪里入手分析和调整。