📚 课程目录第1章 SmartNIC与可编程数据面导论

1. SmartNIC与可编程数据面导论

在传统服务器中，网卡只负责把物理链路上的比特搬进主机内存，协议解析、连接跟踪、安全策略、负载均衡等逻辑全部由 CPU 上的软件栈完成。当链路速率从 10GbE 提升到 100GbE 甚至 400GbE 时，CPU 每包处理预算被压缩到纳秒级，单纯依靠内核协议栈已经无法同时满足吞吐、时延与功耗要求。SmartNIC（智能网卡）正是为应对这一矛盾而出现的硬件形态：它在网卡上集成可编程处理单元、专用加速引擎与独立内存，把一部分原本属于主机 CPU 的数据面工作下沉到网卡侧执行。

SmartNIC的三种典型形态

从硬件组织方式看，SmartNIC大致可分为三类。第一类是基于 ASIC 的固定功能网卡，卸载能力由芯片固化，例如校验和卸载、TSO/LRO、VXLAN 隧道封装，优点是功耗与成本低，缺点是协议演进时无法重新编程。第二类是基于 FPGA 的可编程网卡，逻辑以硬件电路形式实现，可做到线速转发与极低时延，典型场景是金融行情加速、自定义隧道封装，代价是开发周期长、逻辑资源有限。第三类是基于多核 SoC（如 ARM 阵列）的网卡，网卡上运行完整的操作系统与网络协议栈，可承载防火墙、存储前端、虚拟交换等复杂业务，灵活性最高，但每包处理时延高于 FPGA 方案。实际产品常采用混合架构，例如 FPGA 负责快速路径、ARM 核负责慢速路径与控制面。

硬件架构与数据通路

理解 SmartNIC 的关键，是看清数据包从光模块到主机内存之间经过了哪些处理单元。下图给出一个典型的可编程 SmartNIC 内部结构：报文从 PHY/MAC 进入后，先经过解析与分类模块提取五元组、隧道头等字段，再由可编程流水线执行匹配-动作，命中加速路径的报文直接由 DMA 写入主机指定队列，需要复杂处理的报文则上送到片上 CPU 或主机协议栈。

图中绿色部分是数据面核心：报文进入后先被解析成协议头字段集合，再依次经过若干张匹配-动作表。每张表由若干条流表项组成，匹配键可以是目的 MAC、五元组、隧道 VNI 或自定义字段，动作则包括转发到指定端口、改写字段、丢弃、复制到镜像口、上送控制面等。黄色部分是流水线依赖的状态资源，例如连接跟踪表、计数器与寄存器，它们让无状态转发升级为有状态处理。橙色路径代表慢速路径：无法在流水线内完成的报文交给片上 CPU，由它运行 Linux 或专用固件处理后再决定转发或丢弃。

P4 在 SmartNIC 中的位置

P4 是一种描述数据面行为的领域特定语言。它不规定硬件如何实现，而是声明“报文长什么样、按什么字段查表、命中后做什么动作”。以最简单的 IPv4 转发为例，P4 程序会定义以太网与 IPv4 头部结构，声明一个解析器按 etherType 分支，再定义一张名为 ipv4_routing 的表，匹配键为 dstAddr，动作为 set_next_hop 与转发端口。编译器把这段程序翻译成目标网卡可加载的配置，运行时由控制面通过 P4Runtime 向表中插入具体表项。这样，同一份 P4 源码经过不同后端编译，可以分别部署到 FPGA 网卡、ASIC 交换机或软件交换机上，这正是可编程数据面“一次描述、多端执行”的价值所在。

工具链与实验环境搭建

本课程后续实验以开源工具链为主，建议在 Ubuntu 22.04 或 24.04 上搭建。核心组件包括：p4c 编译器（把 P4 源码编译为中间表示与目标配置）、BMv2 软件交换机（simple_switch_grpc，用于在纯软件环境验证逻辑）、PI/P4Runtime 控制面库，以及 Mininet 用于构造多主机拓扑。安装完成后可用以下命令验证环境是否就绪：

# 检查 p4c 编译器
p4c --version
# 预期输出类似：p4c 1.2.4.3 (SHA: ...)

# 启动 BMv2 软件交换机（加载编译产物）
sudo simple_switch_grpc \
  --device-id 0 \
  -i 1@veth1 -i 2@veth2 \
  --log-console \
  build/basic.json

# 另开终端，用 P4Runtime 下发一条表项
python3 controller/add_entry.py \
  --table ipv4_routing \
  --match "10.0.2.2" \
  --action set_next_hop --param 00:00:00:00:00:02

判断环境是否正常，可以观察三点：一是 p4c 编译无报错并生成 .json 与 .p4info 文件；二是 simple_switch_grpc 启动后打印出端口与流水线加载信息；三是下发流表后，用 ping 或 scapy 发包，能在交换机日志中看到对应表项命中计数增加。若编译报错，优先检查 P4 版本与 p4c 后端是否匹配；若表项下发失败，检查 P4Runtime 的 device-id 与 gRPC 端口是否一致。

建议为每章实验建立独立目录，把 P4 源码、编译产物、控制面脚本与抓包文件分开存放，便于对比不同版本的流水线行为。

需要强调的是，SmartNIC 的可编程能力并不意味着所有逻辑都应下沉。判断一个功能是否适合卸载，通常看三点：是否处于每包必经路径、是否对时延敏感、是否已有稳定的匹配-动作抽象。连接跟踪、隧道封装、访问控制列表属于典型适合项；而需要复杂状态机或大量内存的业务，往往仍留在主机侧更经济。理解这条边界，是后续设计 P4 流水线时做出合理取舍的前提。