3. 网卡硬件卸载能力概述

现代高性能网卡(NIC)已从单纯的物理帧收发设备,进化为具备复杂数据平面处理能力的智能硬件。将数据路径中可模式化的操作从CPU卸载到网卡硬件,是DPDK实现零拷贝、低延迟的关键前提。本章系统梳理常见网卡卸载特性,并建立硬件卸载与软件处理的权衡决策模型。

3.1 常见网卡卸载特性全景

下表汇总了Intel XL710、Mellanox ConnectX-6、Broadcom NetXtreme-E等主流智能网卡支持的六大类硬件卸载特性,涵盖其功能定位、典型加速比及适用场景。

卸载特性 全称 功能定位 典型加速比 适用场景
RSS Receive Side Scaling 多队列负载均衡 线性扩展至N核 通用多核收包
FDIR Flow Director 精确流定向 单流锁定单核 VIP流、控制面
TSO TCP Segmentation Offload 大段分片卸载 5~10x TCP大块发送
LRO Large Receive Offload 大段合并卸载 3~8x TCP大块接收
Checksum Offload 校验和卸载 L3/L4校验计算 节省CPU 5~15% 所有IP/TCP/UDP
VXLAN Offload VXLAN封装卸载 隧道加解封装 2~5x Overlay网络
关键认知: 卸载不是“全有或全无”。RSS和FDIR解决的是流到核的映射问题;TSO/LRO解决的是分段粒度问题;Checksum Offload解决的是校验计算问题。三者可以独立启用,但存在协同约束。

3.2 核心卸载特性详解

3.2.1 RSS(接收端缩放)

RSS通过硬件哈希函数将入站数据包均匀分布到多个接收队列,每个队列绑定一个CPU核,实现流级别的并行处理。哈希元组通常为:(源IP、目的IP、源端口、目的端口、协议)。

  • 哈希算法: Toeplitz哈希(默认)、对称哈希(Mellanox扩展)。
  • 重哈希(RSS Rehash): 当队列数变化时,硬件自动重新计算哈希映射,无需软件干预。
  • 局限: 无法保证特定流固定到指定核;多流冲突时只能概率均衡。
RSS 多队列哈希分发流程 RSS 硬件哈希分发流程 入站数据包 Toeplitz 哈希计算 重哈希(可选) 队列 0 队列 1 队列 2 队列 3 说明 哈希结果对队列数取模, 同一流始终映射到 同一队列。

3.2.2 FDIR(流定向)

FDIR允许软件通过精确匹配规则将特定五元组或自定义元组的流定向到指定队列。与RSS的概率分发不同,FDIR提供确定性的流到核绑定。

  • 规则存储: 硬件TCAM或SRAM,典型容量2K~32K条。
  • 匹配模式: 精确匹配、通配符匹配、范围匹配。
  • 动作: 定向到队列、丢弃、修改元数据、触发中断。
  • DPDK接口: rte_eth_dev_filter_ctrl() + RTE_ETH_FILTER_FDIR。
实践陷阱: FDIR规则数量超过硬件容量时,新规则会静默失败(返回成功但未生效)。务必在初始化时通过 rte_eth_dev_info_get() 查询 max_fdir_filters 字段,并预留20%余量。

3.2.3 TSO / LRO

TSO(TCP分段卸载)允许应用层发送最大64KB的超级数据包,网卡硬件按MSS自动分片并添加TCP/IP头部。LRO(大接收卸载)是反向操作,将多个连续TCP段合并为一个大包提交给协议栈。

特性 方向 最大卸载长度 CPU节省 DPDK控制
TSO 发送 64KB ~30% tx_offloads |= DEV_TX_OFFLOAD_TCP_TSO
LRO 接收 取决于硬件 ~20% rx_offloads |= DEV_RX_OFFLOAD_TCP_LRO

3.2.4 Checksum Offload

网卡硬件在发送时自动计算并填充IP/TCP/UDP校验和;在接收时验证校验和并标记结果在描述符中。DPDK应用通过 mbuf->ol_flags 中的 PKT_RX_IP_CKSUM_GOOD 等标志位直接获取校验结果,无需软件计算。

3.3 硬件卸载与软件处理的权衡

并非所有场景都适合启用硬件卸载。以下决策树帮助工程师在性能、灵活性、可调试性之间做出选择。

硬件卸载 vs 软件处理权衡模型 硬件卸载 vs 软件处理权衡决策模型 启用硬件卸载? ✅ 硬件卸载 ✅ 软件处理 低延迟、高吞吐 固定模式、可预测 调试困难、黑盒 灵活、可编程 快速原型、易调试 CPU开销高

3.4 权衡决策清单

在实际项目中,建议按以下优先级进行决策:

  1. 功能完整性: 硬件卸载是否支持所需协议变体(如VXLAN GPE、Geneve)?不支持则必须走软件。
  2. 性能收益: 使用DPDK的 rte_eth_stats_get() 对比卸载开启/关闭时的吞吐和CPU占用。
  3. 调试复杂度: 卸载开启后,tcpdump抓到的包是分段/合并后的形态,增加排障难度。开发阶段建议关闭TSO/LRO。
  4. 硬件资源: FDIR规则数、RSS队列数、TCAM容量是否满足业务峰值?不足时回退到软件分类。
  5. 功耗约束: 某些低功耗场景(如ARM服务器)硬件卸载的功耗收益可能被芯片内部DMA开销抵消,需实测。
推荐实践: 在DPDK应用初始化阶段,使用 rte_eth_dev_configure() 的 rx_offloads 和 tx_offloads 位掩码按需开启卸载特性。对于RSS和FDIR,建议先以RSS作为基线,对VIP流叠加FDIR精确规则,形成RSS + FDIR混合模式。

3.5 本章小结

  • RSS提供流级别的队列负载均衡,是通用多核收包的基石。
  • FDIR提供确定性的流定向,适用于需要精确控制流到核映射的场景。
  • TSO/LRO通过批量处理减少CPU中断和协议栈开销,但会改变抓包形态。
  • Checksum Offload是零成本的卸载,建议始终开启。
  • 卸载决策需在性能、灵活性、可调试性三者间权衡,没有银弹。