——从 IRQ → softirq → TCP 看“性能优化”与“兜底机制”的本质区别
在 Linux 网络调优的实践中，RPS（Receive Packet Steering）几乎是一个绕不开的话题。它经常被描述为一种“负载均衡手段”，甚至被直接归入“性能优化技巧”的范畴。
然而，在内核网络语境下，有一句看似尖锐却极其严谨的判断：
RPS 解决的是“没办法”的情况，而不是性能优化手段。
这句话之所以反复引发争议，并不在于它是否“绝对正确”，而在于它触及了一个更深层的问题：Linux 内核中，对“性能优化”的定义，与我们在工程直觉中的理解，并不相同。
要真正理解这句话，必须回到 Linux 网络栈最底层的执行模型，从 IRQ → softirq → TCP 的完整路径出发，重新审视 RSS、RPS、RFS、XPS 这些机制存在的边界与代价。
一、先澄清概念：Linux 内核语境下的“性能优化”
在很多工程讨论中，“性能优化”往往意味着：
CPU 没用满 → 想办法摊开
某个核打满 → 把负载均衡到别的核
系统卡 → 用更多资源顶上去
这种理解在应用层、分布式系统中往往是成立的，但在 Linux 内核，尤其是网络栈中，却是高度危险的。
内核对“优化”的核心判断标准只有一个：
是否降低了“每个包”的确定性处理成本
而不是：
内核工程师关心的是：
fast path 是否变短
是否引入新的 cache miss
是否引入跨 CPU / NUMA 访问
是否增加不可预测的调度和同步
凡是引入固定、不可消除成本的机制，在内核语境中，都不能被称为优化。
二、Linux 网络接收路径的性能核心：CPU ownership 传递链
理解 RSS 和 RPS 的根本差异，必须先理解 Linux 网络接收路径真正的“骨架”。
表面上看，网络包经历了多个阶段，但在性能视角下，它们构成了一条极其关键的隐含链路：
IRQ → softirq → 协议栈（TCP / UDP）
这不是简单的阶段划分，而是一条CPU ownership 的连续传递链。
1. IRQ：ownership 的起点
在现代 NIC 上，接收路径的第一步就已经决定了性能上限：
在这一刻，已经确定了：
数据最初“属于”哪个 CPU
cache line 的初始归属
内存访问是否本地化
性能的命运，从 IRQ 阶段就已经开始被书写。
2. softirq / NAPI：ownership 的延续
IRQ handler 本身几乎不做处理，只是调度 NAPI：
随后由 net_rx_action() 在同一 CPU 上执行：
poll RX queue
构造 skb
决定是否进入协议栈
关键点在于：
softnet_data 是 per-CPU
backlog 队列是 per-CPU
skb 的 cache line 仍然是热的
在没有额外干预的情况下，CPU ownership 并没有发生改变。
3. TCP：对 CPU 连续性的强依赖
进入协议栈后，TCP 对 CPU 局部性的依赖尤为明显：
socket lock
拥塞控制状态
RTT / 重传队列
out-of-order buffer
这些数据结构高度 cache 敏感，并且隐含假设：
同一条 flow 的包，会在同一个 CPU 上被反复处理
这不是巧合，而是 TCP 性能设计的前提。
三、RSS：真正的性能设计，而不是“负载均衡”
RSS（Receive Side Scaling）经常被误解为一种“把包分散到多个 CPU 的均衡机制”。但 RSS 的真正价值，从来不在“均衡”，而在时机。
RSS 的关键特征是：
硬件在 DMA 之前完成 hash
决定写入哪个 RX queue
RX queue 与 CPU 绑定
IRQ、softirq、协议栈天然在同一 CPU
其结果是：
skb 从未跨 CPU
cache line 不发生 bounce
NUMA 亲和性天然保持
fast path 极短且稳定
RSS 并没有“修正错误路径”，它只是让包一开始就站对了队。
这正是内核语境下“性能优化”的典型范式。
四、RPS：为什么它是“没办法”的兜底机制
RPS（Receive Packet Steering）的介入点，决定了它的命运。
RPS 发生在：
napi_poll()→ netif_receive_skb()→ enqueue_to_backlog()
此时已经是一个不可逆的状态：
skb 已经被当前 CPU touch
cache ownership 已经建立
DMA 和 NUMA 位置已经固定
RPS 所做的事情是：
这本质上是一次事后搬运。
五、RPS 的隐性成本：cache 与 NUMA 的“硬账本”
1. cache line 层面的固定成本
一个最小的 skb 至少涉及：
struct sk_buff
data buffer
skb_shared_info
在 RPS 场景下，这些对象必然经历：
这是100% 会发生的固定成本，而不是“可能发生”。
保守估算：
2. PPS 场景下的线性放大
在高 PPS 场景中，这种固定成本会被无情放大：
这还不包括：
backlog 队列管理
IPI 抖动
softirq 调度不确定性
3. NUMA 场景下的阶跃式退化
在 NUMA 系统中，RPS 的代价更为致命：
这不是“慢一点”，而是性能塌陷。
六、NFV / XDP 场景下，RPS 为什么是反优化
NFV、XDP、高性能转发系统有一个共同前提：
数据平面追求的是：固定 CPU + 固定 cache + 最短路径
而不是 CPU 使用率的“好看”。
在这些场景中：
RPS 引入的固定成本，往往超过了真正的业务逻辑本身。
此外：
XDP 的设计目标本就是绕过 skb 和协议栈
能被 XDP 处理的流量，根本不需要 RPS
一旦进入 RPS，说明路径选择已经失败
因此，在 NFV / XDP 场景中：
RPS 不是“不够好”，而是方向性错误。
七、重新理解那句争议判断
回到那句最初引发讨论的话：
RPS 解决的是“没办法”的情况，而不是性能优化手段。
在内核语境下，它的真实含义是：
当硬件无法提供 RSS
当 RX queue 数量不足
当虚拟网卡、veth、tap 没有硬件能力
当系统即将因为单核 softirq 打满而失衡
RPS 接受固定性能损耗，换取系统“不偏、不炸”。
这不是“追求最优”，而是避免最差情况。
八、兜底机制与性能设计的根本分界
性能优化的目标，是让数据少走路；
RPS 的前提，是承认数据已经走错了路，只能再搬一次。
或者更直白一点：
RSS 在链路起点建立秩序，RPS 在链路中段打破秩序。
理解了这一点，就不难明白：
为什么 RPS 在某些场景下“有用”，但在真正追求极致性能的系统中，却必须被严格限制甚至禁用。
