RSS / RFS / XPS

1. RSS

Receive Side Scaling, 解决的问题是：接收到的包应该发到哪个 RX queue，Toeplitz hash 通过五元组（src_ip, dest_ip, src_port, dest_port, protocol）计算一个32bit的值，然后取低几位，通过RSS间接表映射到 queue。

RSS 不会跨核共享

每个RX queue绑定独立的 MSI-X 中断， 然后独立绑定核心，包从DMA进来到 NAPI Poll 到 协议栈处理，始终都在一个核心上，没有跨核心数据。

2. RFS

Receive Flow Steering，RFS 解决的是：接收到的 flow 应该由哪个 CPU 处理。RFS 维护一个全局流表，flow (src_ip, dst_ip, src_port, dst_port) → 目标 CPU。在DPDK / AF_XDP 等 RSS 绑定核心的场景下没用，一般用在应用不绑核或者频繁迁移的时候。容器环境，容器IP变化频繁，RSS静态哈希可能不均衡，RFS 动态修正。

3. XPS

Transmit Packet Steering，解决的是发出去的包应该在哪个TX queue上。

建立 CPU 到 TX queue 的映射，一个CPU 只用一个 TX queue发包

• 不同的CPU用不同的 TX queue，无锁竞争
• 每个TX queue 的 descriptor ring 是 per-CPU独占的，发包全程在 local cache 上完成

# TX queue 0 → CPU 0
echo 1 > /sys/class/net/eth0/queues/tx-0/xps_cpus