Linux XPS：消除 VPN 网关发送队列锁竞争优化指南

支撑数千条并发加密隧道的现代高性能 VPN 网关，对系统双向对称吞吐能力有着极高要求。在入站方向，通过 Receive Side Scaling（RSS）与 Receive Packet Steering（RPS）等技术能够均衡地将外来数据包分流至不同 CPU 核心；然而在出站方向（egress），高负载系统却常常遭遇意料之外的性能衰减。

在配备 10GbE、25GbE 或 100GbE 多队列网卡（Multi-Queue NIC）的多核服务器上，数据包发送路径极易受到内核自旋锁竞争（lock contention）的制约。当多个 CPU 核心尝试同时将出站流量压入同一个硬件发送队列时，自旋锁会导致处理流程被迫串行化。这种串行化不仅消耗大量的 CPU 轮询周期，引发跨处理器的 CPU 缓存颠簸，还会导致网络时延在 99 分位（p99）出现剧烈抖动。

集成于 Linux 内核网络子系统的 Transmit Packet Steering（XPS）技术，彻底化解了这一核心瓶颈。通过在发送端 CPU 核心（或接收队列）与网卡物理发送队列之间建立确定的静态映射，XPS 排除了队列自旋锁开销，极大提升了边界网关节点的内存子系统效率。

---

Tx Lock Contention: 多核架构下的出站发送性能瓶颈

要理解发送瓶颈的成因，必须梳理 Linux 内核在多队列网卡硬件上分发数据包的完整链路：

1. 报文生成与转发：上层应用程序、虚拟隧道接口（例如 WireGuard 的 wg0）或底层转发逻辑构建出站套接字缓冲区（sk_buff）。
2. 目标队列选取：内核协议栈调用 net/core/dev.c 中的 dev_pick_tx() 函数，计算并确定目标硬件发送队列（struct netdev_queue）。
3. 获取发送排他锁：在通过驱动程序的 ndo_start_xmit() 将报文正式推入硬件环形缓冲区（ring buffer）之前，内核必须先获取该发送队列的专属自旋锁：__netif_tx_lock()。

未启用 XPS 时的发送竞争（多核心争抢单一物理队列）：

核心 0 ──► [ dev_queue_xmit() ] ──┐
                                  ├──► [ 自旋锁 __netif_tx_lock() ] ──► [ 发送队列 0 ]
核心 1 ──► [ dev_queue_xmit() ] ──┤    （严重的自旋等待与 CPU 停滞）
                                  │
核心 2 ──► [ dev_queue_xmit() ] ──┘

若未对队列进行专门映射，系统默认仅依赖常规的流哈希（skb_tx_hash()）分配队列。在对称 VPN 隧道场景中，数以千计的客户端连接具有高度相似的外层 UDP 封装属性或哈希分布，不同核心不可避免地会在同一时刻将报文分发至相同的物理发送队列。

当多个 CPU 核心争夺 __netif_tx_lock() 时，处理线程会陷入忙等待（busy-wait）自旋循环。在 32 核、64 核乃至 128 核的高密度服务器上，锁竞争开销呈指数级扩散。性能分析工具 perf top 常常显示大量 CPU 资源损耗在 queued_spin_lock_slowpath 锁竞争中，而非用于有价值的密码学计算或报文转发。

---

Architectural Mechanics: Linux XPS 的核心运行机制

Transmit Packet Steering 在 CPU 执行上下文与网卡硬件发送队列之间建立了一层可灵活定制的路由映射。XPS 主要支持两种工作模式：基于 CPU 核心的映射与基于接收队列的映射。

1. 基于 CPU 核心的队列映射 (xps_cpus)

基于核心的 XPS 将指定的 CPU 核心独占绑定至专属的硬件发送队列。在 sysfs 虚拟文件系统中，每个物理发送队列均提供一个名为 xps_cpus 的位掩码配置入口。完成配置后：

• 每个 CPU 核心仅向其分配的专属网卡队列发送报文（或向特定独立队列组轮询）。
• 若网卡物理发送队列数量等于或大于活跃 CPU 核心数，每个核心将获得完全互不干扰的独立发送信道。
• 由于任意时刻只有一个 CPU 核心访问特定的 netdev_queue 结构，获取 __netif_tx_lock() 成为近乎无锁的零竞争操作，核心无需任何自旋等待即可推入数据包。

基于 CPU 映射的无锁高效发送架构（1:1 核心对队列绑定）：

核心 0  ──► [ xps_cpus = 0x1 ] ──► [ 专属发送队列 0 ] ──► [ 物理网络介质 ]
核心 1  ──► [ xps_cpus = 0x2 ] ──► [ 专属发送队列 1 ] ──► [ 物理网络介质 ]
核心 2  ──► [ xps_cpus = 0x4 ] ──► [ 专属发送队列 2 ] ──► [ 物理网络介质 ]
核心 3  ──► [ xps_cpus = 0x8 ] ──► [ 专属发送队列 3 ] ──► [ 物理网络介质 ]

2. 基于接收队列的对称映射 (xps_rxqs)

现代网络适配器与 VPN 交互通常承载对称的双向数据流。当网关在第 $N$ 号接收队列（Rx 队列）收到数据包时，处理中断的 CPU 核心早已在自身的 L1/L2 局部缓存中加载了报文协议头、连接状态及路由信息。

启用 xps_rxqs 可以将发送队列与接收该会话数据的接收队列精准绑定：

• 从 Rx 队列 0 接收的数据包，其回复报文（例如 TCP 确认包 ACK 或隧道重连响应）必定由 Tx 队列 0 发送。
• 该对称性保证了发送操作由刚刚处理过接收任务的同一个 CPU 核心执行，杜绝了跨核心间对 CPU 高速缓存的破坏。

---

NUMA Topology and Cache Locality: 多路网关中的内存协同

在多物理插槽（例如双路 AMD EPYC 或 Intel Xeon）大型服务器上，非一致性内存访问（NUMA）架构对网络传输速率有着决定性影响。

跨插槽颠簸与总线通信瓶颈

服务器上的各个 PCIe 网卡插槽在物理上直接依附于特定 NUMA 节点的根复合物。如果 NUMA 节点 1 上的核心向依附于 NUMA 节点 0 的网卡发送报文，且未配置感知 NUMA 的 XPS 映射：

1. 互联总线拥塞：发送核心必须通过处理器间的高速互联总线（如 AMD Infinity Fabric 或 Intel UPI）传输描述符指针与 DMA 地址。
2. L3 缓存行剧烈颠簸：队列自旋锁 __netif_tx_lock() 和环形缓冲区指针在两个物理插槽的 L3 缓存片区之间反复迁移失效。
3. 长尾延迟波动：跨插槽内存访问的时钟周期显著高于本地插槽访问，导致数据包传输抖动明显加剧。

按照 NUMA 物理边界对齐 XPS 位掩码，能够保障各 CPU 核心仅向归属于本地 NUMA 节点的网卡队列提交报文，从而把内存交互约束在本地，保护系统互联总线带宽。

---

内核配置：在 Linux 中调优 XPS 与队列限制

要完成 XPS 的最佳配置，运维工程师需要枚举网络接口的硬件队列能力，精确计算 CPU 位掩码，并协同驱动队列限额共同生效。

1. 配置 CPU 核心与发送队列的位掩码

以具有 4 个核心与 4 个发送队列的网卡 eth0 为例，建立 1:1 独立映射：

# 查看网络接口 eth0 所有的物理发送队列
ls -d /sys/class/net/eth0/queues/tx-*

# 将 CPU 核心 0（掩码 0x1）绑定至发送队列 Tx 0
echo "1" | sudo tee /sys/class/net/eth0/queues/tx-0/xps_cpus

# 将 CPU 核心 1（掩码 0x2）绑定至发送队列 Tx 1
echo "2" | sudo tee /sys/class/net/eth0/queues/tx-1/xps_cpus

# 将 CPU 核心 2（掩码 0x4）绑定至发送队列 Tx 2
echo "4" | sudo tee /sys/class/net/eth0/queues/tx-2/xps_cpus

# 将 CPU 核心 3（掩码 0x8）绑定至发送队列 Tx 3
echo "8" | sudo tee /sys/class/net/eth0/queues/tx-3/xps_cpus

对于 CPU 核心数量多于网卡物理队列的场景，应当将共享同一物理 L3 缓存簇的核心聚拢划分到同一个 Tx 队列位掩码中，使缓存行失效的惩罚降至最低。

2. 结合 Byte Queue Limits (BQL) 实现出站防拥塞

XPS 从根本上排除了软件锁竞争，但为了避免硬件队列堆积形成缓冲区膨胀（bufferbloat），还需要配合 Byte Queue Limits（BQL）机制。BQL 在每个驱动队列内部动态运行：

# 查看 Tx 队列 0 动态计算得出的当前字节限制
cat /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit

# 实时监测处于硬件排队状态的在途数据字节数
cat /sys/class/net/eth0/queues/tx-0/byte_queue_limits/inflight

XPS 与 BQL 的协同构建了理想平衡：XPS 确保各核心能够即刻、无锁地将报文推入队列，而 BQL 则精准压制环形队列深度，使整体排队延迟始终处于亚毫秒区间。

---

架构对比：常规发送与启用 XPS 性能测试对照

下表汇总了在 40GbE 边界路由器上，以 64 字节至 1420 字节混合报文满载测试所得的关键指标：

---

RiceGuard 架构：无锁发送通道集成实践

在 VPNRice 整体架构中，RiceGuard 边缘网关采用了高并行度多线程网络处理引擎，专为打满数千兆上行链路而设计。每个负责加解密运算的工作线程都会通过 CPU 亲和性固定在专属核心上。

RiceGuard 发送管道深度整合了内核 XPS 队列映射：

/* RiceGuard 线程亲和性与发送通道协同初始化 */
int configure_worker_egress_affinity(int worker_id, int core_id) {
    cpu_set_t cpuset;
    CPU_ZERO(&cpuset);
    CPU_SET(core_id, &cpuset);

    /* 严苛绑定工作线程至指定 CPU 核心 */
    if (pthread_setaffinity_np(pthread_self(), sizeof(cpu_set_t), &cpuset) != 0) {
        perror("pthread_setaffinity_np");
        return -1;
    }

    /* 套接字出站报文将直接落入对应的专属 XPS 发送队列 */
    return 0;
}

通过保证 RiceGuard 密码学线程在完成 WireGuard 报文封装后，直接在该核心绑定的专属 XPS 队列输出，报文无需争夺任何自旋锁便能流经驱动环形缓冲区。

结合 RiceGuard 零拷贝（zero-copy）数据通道，这套经过 XPS 调优的发送体系，即使面对海量多千兆突发网络流，也能为企业级虚拟专用网隧道提供始终稳定在亚毫秒级的低延迟传输。