02 ConnectX-5/6/7网卡架构与ASAP2卸载引擎初探

🧭网卡内部流水线与ASAP2卸载引擎：从数据包到硬件路径

输入、处理和输出的检查项

在OVS卸载场景中，理解ConnectX网卡内部的数据处理流水线是第一步。当一条流表规范被卸载到硬件后，数据包不再经过主机内核协议栈，而是直接在网卡内部完成匹配与转发。这个过程的正确性依赖于网卡内部的“eSwitch”角色——它本质上是一个硬件实现的虚拟交换机，负责在物理端口、VF（Virtual Function）和上行链路之间转发流量

ConnectX-5/6/7系列网卡的核心差异在于内部流水线的处理能力与ASAP2（Accelerated Switching and Packet Processing）引擎的演进。以ConnectX-6 Dx为例，其内部流水线包含：数据包解析（Parser）→ 流表查找（Flow Table Lookup）→ 动作执行（Action Execution）→ 数据包修改（Packet Modification）→ 转发输出（Egress）。其中，流表查找阶段直接对接ASAP2引擎，该引擎维护了一个硬件转发表，其表项由用户态OVS通过devlink或mlx5驱动下发

一个容易出错的步骤是流表下发后的。当OVS下发一条卸载规范时，驱动层会尝试将其写入硬件TCAM。如果硬件表项已满或规范格式不兼容（例如使用了硬件不支持的匹配字段），驱动会静默回退到软件处理，但不会主动报错。此时，必须通过ovs-appctl dpctl/dump-flows检查offloaded标记，确认规范是否真正驻留在硬件中

⭐eSwitch角色与数据面隔离：硬件卸载的边界条件

eSwitch（嵌入式交换机）是ConnectX网卡实现硬件卸载的核心组件。它工作在网卡内部，负责管理所有VF与物理端口之间的流量。在OVS卸载场景中，eSwitch扮演了“硬件OVS”的角色：它接收来自物理端口或VF的数据包，根据硬件流表执行转发、封装/解封装（VXLAN/GENEVE）、修改MAC地址等动作

eSwitch的配置通过devlink dev eswitch set命令完成，关键参数包括mode（legacy或switchdev）和inline-mode。只有将eSwitch设置为switchdev模式，才能启用硬件卸载功能。以下是典型的配置命令序列：

# 将eSwitch设置为switchdev模式
devlink dev eswitch set pci/0000:03:00.0 mode switchdev
# 确认模式已生效
devlink dev eswitch show pci/0000:03:00.0
# 检查VF数量与状态
echo 4 > /sys/class/net/ens1f0np0/device/sriov_numvfs
ip link show ens1f0np0

阅读这段代码时，重点看7网卡架构的伪代码，以及它如何用稳定性与可观测性证明结果可复测。

一个常见的配置陷阱是inline-mode的匹配。ConnectX-5要求inline-mode必须设置为transport或network，否则硬件无法解析数据包头部，导致卸载失败。ConnectX-6及之后版本默认支持全模式解析，但若遇到卸载不生效，仍应通过devlink dev param show检查flow_steering_mode参数

⭐ConnectX-5的技术资产与验证方式

为了确保硬件卸载正确生效，需要建立一套可复用的验证流程。以下是一份检查清单，用于在部署或排障时逐项确认：

除了检查清单，还需要一套判断标准表来快速评估卸载效果：