Linux Network RSS RPS 疑惑

碰到 Linux 网卡性能，中断紧张等问题时，就难免不谈到 RSS 和 RPS ， RFS； 这里记录些理解， 希望对大家解惑有些帮助；

这张图很好展示了 RSS，RPS 机制的在整个数据包处理流程中的作用位置；

1. 数据包到达支持 RSS 特性的网卡， hash 数据包到队列 （数据存入 ring_buf, 存指存到队列）

2. 队列存入数据，产生硬中断， 等待 cpu 处理

3. cpu 处理中断，将数据从队列取走，将数据放到 CPU 处理队列，产生软中断，继续后面的协议栈处理

第三步骤中， 包含了中断的上半部和下半部；这里就涉及 RPS 的工作

上半部处理的 CPU 对应队列 IRQ 处理的 CPU， 一个队列 IRQ 由哪些 CPU 处理，涉及中断亲和性的配置； irqblance 程序也是在自动的调整这个中断亲和性； 拓扑结构越近的处理起来越快； 所以有很多追求性能的配置是 1:1 配置 队列中断和 CPU 的对应关系； 下面图是一个配置的实例；

那中断的下半部由谁执行那？看下面的函数，基本就能明确；

1. 如果 不开启 RPS， 数据包就会放到当前 CPU 的队列中， 即 执行硬中断的 CPU == 执行软中断的 CPU

2. 如果 开启 RPS， 那么数据包 hash 选择配置的 CPU，CPU 中断进一步平衡一次；执行硬中断的 CPU ！= 执行软中断的 CPU

所以在网卡支持 RSS 时，根据队列亲和 CPU 的配置，就已经平衡了 IRQ，因为 RSS 队列已经是 hash 平均的， 所以基本都是不建议在 RSS 基础上，再开启 RPS； 这也是内核文档中给的建议， 同时也指出了一种 RSS 和 RPS 同时开启的情况， 就是 RSS 硬件队列数少于 CPU 数时，可以开启 RPS 到一组相近的 CPU。

RPS 只跟据元组 hash 平衡，不考虑应用位置；RFS 则补充了这点，目的还是更好的选择软中断的 CPU；

虚拟设备是怎么工作的那，如容器常用的 veth ..

veth 是一个设备对， 一端发，对端收； 在内核数据结构上其实很容易 ref 到对端设备；

不涉及具体硬件设备， 上图左半部分就完成传输；代码也较少，我们参考下；

发送时，找到对端设备，直接推到接收 CPU 的队列中， 不开启 RPS 时，就是这端谁发的，谁就负责对端取； 也可以开启 RPS 再 hash 平衡到多个 CPU，除了减少点乱序，效率可能也不高；

目前众多 容器网络方案，还未见 veth 开启过 RPS； 可能也是一个无聊的问题吧，很少人讨论；