4. 多队列技术原理：RSS（Receive Side Scaling）核心概念

随着网络带宽从 1Gbps 向 10Gbps、25Gbps 乃至 100Gbps 演进，单核 CPU 已无法独立完成线速收包处理。RSS（Receive Side Scaling，接收端缩放）是网卡多队列技术的基石，它允许网卡将入站数据流分散到多个硬件接收队列，进而分发至不同 CPU 核心并行处理，从根本上消除单核瓶颈。

4.1 RSS 解决的问题：单队列瓶颈

在传统单队列 NIC 模型中，所有入站数据包共享一个接收描述符环（RX Ring），由单个 CPU 核心负责中断处理与协议栈上送。该模型存在三个致命缺陷：

• 中断风暴：高吞吐下单个 CPU 被中断淹没，无法调度用户态进程。
• 缓存抖动：单核 L1/L2 缓存无法容纳海量连接上下文，频繁 cache miss。
• 锁竞争：协议栈全局锁（如 sock_alloc）在单核上无意义，但多核场景下若仍由单核处理，则成为伪共享瓶颈。

4.2 RSS 核心机制：哈希分发

RSS 的核心是一个可编程的 Toeplitz 哈希引擎，位于网卡 MAC 层与 DMA 引擎之间。每个入站数据包经过哈希计算后，其结果用于索引一个重定向表（Indirection Table），从而决定该包进入哪个接收队列。

4.2.1 哈希输入元组

4.2.2 重定向表与队列映射

哈希值（通常为 32 位）并不直接对应队列编号，而是通过一个 间接表（Indirection Table，IT） 进行映射。IT 的大小通常为 128 或 512 项，每项存储一个队列 ID（0 ~ N-1）。

// 伪代码：RSS 队列选择流程
uint32_t hash = toeplitz_hash(packet_header, rss_key);
uint32_t index = hash & (indirection_table_size - 1);
uint16_t queue_id = indirection_table[index];
// 将 packet DMA 到 queue_id 对应的 RX Ring

4.3 RSS 硬件架构与数据流

下图展示了 RSS 在网卡内部的完整处理流水线：

4.4 RSS 关键参数与配置

Linux 下通过 ethtool 工具可完整查看和调整 RSS 参数：

# 查看网卡 RSS 队列数
ethtool -l eth0
# 输出示例：
#   Combined: 8
#   RX:        8
#   TX:        8

# 设置 RSS 队列数为 8
ethtool -L eth0 combined 8

# 查看当前 RSS 哈希配置
ethtool -x eth0
# 输出示例：
#   RSS hash function: toeplitz
#   RSS hash key: 6d:5a:56:da:25:5b:0e:c2:41:67:25:3d:43:a3:8f:b0:...
#   RSS indirection table: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 ...

# 自定义 RSS 哈希键（40 字节十六进制）
ethtool -X eth0 hkey 6d:5a:56:da:25:5b:0e:c2:41:67:25:3d:43:a3:8f:b0:...

# 设置 RSS 哈希输入元组（仅 IPv4 TCP）
ethtool -N eth0 rx-flow-hash tcp4 sdfn

4.4.1 哈希输入元组标志

4.5 RSS 与 CPU 亲和性的联动

RSS 仅保证数据包被分发到不同硬件队列，但队列的中断处理程序最终运行在哪个 CPU 核心上，由 中断亲和性（IRQ Affinity） 决定。两者必须联动配置才能实现真正的负载均衡：

1. RSS 层：通过哈希将流散列到不同队列，避免单队列拥塞。
2. IRQ Affinity 层：将每个队列的中断绑定到指定 CPU 核心，确保中断处理与后续协议栈处理在同一核心上完成，最大化缓存局部性。

4.6 RSS 的局限性

• 哈希冲突：不同流可能映射到同一队列，导致局部热点。可通过增大间接表或使用对称哈希缓解。
• 不支持 UDP 多流：UDP 无连接概念，部分网卡默认仅对 IP 对做哈希，导致所有 UDP 流量进入同一队列。
• 虚拟化环境：在 SR-IOV VF 中，RSS 功能取决于物理网卡和 PF 驱动支持，部分 VF 仅支持单队列。
• 无法感知应用负载：RSS 是纯硬件哈希，无法根据 CPU 当前利用率动态调整分发策略。