1. 什么是 RPS？
RPS 是 Receive Packet Steering 的缩写，是网卡硬件功能 RSS（Receive Side Scaling） 的软件实现形式之一，该网络功能是在不支持网卡硬件多队列的情形下，不过 RPS 比 RSS 发生得更晚：它不决定硬件 RX queue/IRQ CPU，而是在驱动已经收上 skb 后，选择后续协议栈处理 CPU，这样可以充分利用 SMP 多 CPU 架构，不至于出现一核有难，多核围观的情况。该功能由 Google 工程师 Tom Herbert 引入。
2. RPS 的实现
以网卡 STMicro MAC 驱动为例，该网卡驱动使用 NAPI，从网卡 RX 中断开始：
stmmac_interrupt()
stmmac_dma_interrupt()
__napi_schedule()
/* 参数 1：当前 CPU 的 softnet_data */
____napi_schedule(this_cpu_ptr(&softnet_data), n);
/*
* 添加 网络数据接收工作 负载。
* 注意，这里没有做实际的数据接收工作。
*/
list_add_tail(&napi->poll_list, &sd->poll_list);
/* 抛出 NET_RX_SOFTIRQ，在 softirq 中调用 net_rx_action() 实际的网络数据接收工作 */
__raise_softirq_irqoff(NET_RX_SOFTIRQ);
上面做了两件工作：
- 1. 添加
网络数据接收工作负载。注意，这里没有做实际的数据接收工作。 - 2. 抛出
NET_RX_SOFTIRQ softirq 事件，这样后续将在 softirq 中调用 net_rx_action() 做网络数据接收处理工作，将数据向上传递给协议栈。
接下来，在 softirq 上下文，将数据向上传递给协议栈，或者通过 RPS 功能派发给其它 CPU 处理：
net_rx_action()
napi_poll()
stmmac_poll()
stmmac_rx()
napi_gro_receive()
napi_skb_finish()
netif_receive_skb_internal()
如果启用了 RPS 功能（CONFIG_RPS=y），在 netif_receive_skb_internal() 中，RPS 功能函数 get_rps_cpu() 决定到底是将数据向上传递给协议栈，还是派发给其它 CPU (的 softirq) 处理：
static int netif_receive_skb_internal(struct sk_buff *skb)
{
...
rcu_read_lock();
#ifdef CONFIG_RPS
if (static_key_false(&rps_needed)) {
struct rps_dev_flow voidflow, *rflow = &voidflow;
/* 模拟网卡硬件多队列, RPS 将数据分流到各个 cpu */
int cpu = get_rps_cpu(skb->dev, skb, &rflow);
if (cpu >= 0) {
ret = enqueue_to_backlog(skb, cpu, &rflow->last_qtail); /* (1) */
rcu_read_unlock();
return ret; /* RPS: 派发给 remote CPU 处理的数据包 */
}
}
#endif
ret = __netif_receive_skb(skb); /* (2) RPS: 给当前 CPU 处理的数据包 */
rcu_read_unlock();
return ret;
}
如果是将数据包向上传递给协议栈，走上面注释 (2) 处的 __netif_receive_skb()；如果是将数据包派发给其它 CPU (的 softirq) 处理，则走 (1) 处的 enqueue_to_backlog() 将接收的 skb 挂接到目标 CPU (的 softnet_data)，并记录接收数据 CPU 的 (softnet_data) 信息：
static int enqueue_to_backlog(struct sk_buff *skb, int cpu,
unsigned int *qtail)
{
struct softnet_data *sd;
unsigned long flags;
unsigned int qlen;
sd = &per_cpu(softnet_data, cpu); /* 目标 CPU 的 sofnet_data */
qlen = skb_queue_len(&sd->input_pkt_queue);
/*
* 传统的、使用非 NAPI 收包方式的驱动:
* . qlen <= netdev_max_backlog: 当前 CPU 的 接收队列尚未满
* . !skb_flow_limit(skb, qlen): 指定了流量限制, 但尚未达到限流上限
*/
if (qlen <= netdev_max_backlog && !skb_flow_limit(skb, qlen)) {
if (qlen) {
enqueue:
/* 将网络设备收到的包放到 softnet_data 收包队列 input_pkt_queue */
__skb_queue_tail(&sd->input_pkt_queue, skb);
input_queue_tail_incr_save(sd, qtail);
rps_unlock(sd);
local_irq_restore(flags);
return NET_RX_SUCCESS;
}
/* Schedule NAPI for backlog device
* We can use non atomic operation since we own the queue lock
*/
if (!__test_and_set_bit(NAPI_STATE_SCHED, &sd->backlog.state)) {
if (!rps_ipi_queued(sd))
/* 数据目标 @cpu 就是当前 CPU */
____napi_schedule(sd, &sd->backlog);
}
goto enqueue;
}
...
}
rps_ipi_queued() 记录要派发目标 CPU 的 (softnet_data) 信息：
/*
* Incoming packets are placed on per-CPU queues
*/
struct softnet_data {
...
#ifdef CONFIG_RPS
struct softnet_data *rps_ipi_list;
#endif
...
#ifdef CONFIG_RPS
/* input_queue_head should be written by cpu owning this struct,
* and only read by other cpus. Worth using a cache line.
*/
unsigned int input_queue_head ____cacheline_aligned_in_smp;
/* Elements below can be accessed between CPUs for RPS/RFS */
call_single_data_t csd ____cacheline_aligned_in_smp;
struct softnet_data *rps_ipi_next;
unsigned int cpu;
unsigned int input_queue_tail;
#endif
...
struct sk_buff_head input_pkt_queue;
...
};
/*
* Check if this softnet_data structure is another cpu one
* If yes, queue it to our IPI list and return 1
* If no, return 0
*/
static int rps_ipi_queued(struct softnet_data *sd)
{
#ifdef CONFIG_RPS
struct softnet_data *mysd = this_cpu_ptr(&softnet_data);
if (sd != mysd) { /* RPS 选择的数据目标 CPU 不是当前 CPU，需要记录 remote softnet_data 并稍后发送 IPI */
sd->rps_ipi_next = mysd->rps_ipi_list; /* 所有 RPS 需 派发给 remote CPU 处理的 sd 列表 */
mysd->rps_ipi_list = sd; /* 记录 RPS 派发给 remote CPU 处理的 最新的 sd */
__raise_softirq_irqoff(NET_RX_SOFTIRQ);
return 1;
}
#endif /* CONFIG_RPS */
return 0; /* RPS 选择的数据目标 @cpu 就是当前 CPU */
}
然后在 net_rx_action() 检查 rps_ipi_queued() 记录的 remote CPU 数据派发信息，如果发现存在，则通知 remote CPU 处理数据：
net_rx_action()
// 1. 记录接收 skb 的 remote CPU 信息
napi_poll()
stmmac_poll()
stmmac_rx()
napi_gro_receive()
napi_skb_finish()
netif_receive_skb_internal()
enqueue_to_backlog()
rps_ipi_queued()
// 2. 检查是否有需要 remote CPU 处理的 skb，如果有，通知它们处理数据
net_rps_action_and_irq_enable(sd);
static void net_rps_action_and_irq_enable(struct softnet_data *sd)
{
#ifdef CONFIG_RPS
struct softnet_data *remsd = sd->rps_ipi_list;
if (remsd) {
sd->rps_ipi_list = NULL;
local_irq_enable();
/* Send pending IPI's to kick RPS processing on remote cpus. */
net_rps_send_ipi(remsd);
} else
#endif
local_irq_enable();
}
static void net_rps_send_ipi(struct softnet_data *remsd)
{
#ifdef CONFIG_RPS
while (remsd) {
struct softnet_data *next = remsd->rps_ipi_next;
/*
* 在远程 CPU @remsd->cpu 上, 异步执行 rps_trigger_softirq(),
* 添加到 远程 CPU @remsd->cpu 的 数据接收工作队列.
*/
if (cpu_online(remsd->cpu))
smp_call_function_single_async(remsd->cpu, &remsd->csd);
remsd = next;
}
#endif
}
smp_call_function_single_async()
generic_exec_single()
arch_send_call_function_single_ipi()
smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC)
...
rps_trigger_softirq()
#ifdef CONFIG_RPS
...
// 在 remote 目标 CPU 上执行 rps_trigger_softirq()
/* Called from hardirq (IPI) context */
static void rps_trigger_softirq(void *data)
{
struct softnet_data *sd = data;
____napi_schedule(sd, &sd->backlog); /* 调度 remote CPU 的 rx 数据接收工作负载 */
sd->received_rps++;
}
#endif /* CONFIG_RPS */
static inline void ____napi_schedule(struct softnet_data *sd,
struct napi_struct *napi)
{
list_add_tail(&napi->poll_list, &sd->poll_list);
__raise_softirq_irqoff(NET_RX_SOFTIRQ);
}
值得一提的是，rps_trigger_softirq() 函数是在网卡初始化接口 net_dev_init() 中设置：
static int __init net_dev_init(void)
{
int i, rc = -ENOMEM;
...
/* 每 CPU sofnet_data 初始化 */
for_each_possible_cpu(i) {
...
struct softnet_data *sd = &per_cpu(softnet_data, i);
...
#ifdef CONFIG_RPS
sd->csd.func = rps_trigger_softirq;
sd->csd.info = sd;
sd->cpu = i;
#endif
...
}
...
}
到此，RPS 的 skb 接收处理的流程就已经分析完了，get_rps_cpu() 选择接收 skb 的目标 CPU 的算法，是整个 RPS 功能的核心之一，本文对此不做展开，对此感兴趣的读者可以参考 一文看懂linux 内核网络中 RPS/RFS 原理。
要注意，从前面的代码分析了解到，当 RX IRQ CPU 通过 NAPI poll 收包，并且其中一些 skb 被 RPS 转移到目标 CPU 时：
- 1. RX IRQ CPU 执行 NET_RX_SOFTIRQ 来跑驱动 NAPI poll
=> RX IRQ CPU 的 /proc/softirqs NET_RX 计数增长 - 2. RPS target CPU 被 IPI 唤醒后执行 NET_RX_SOFTIRQ 来跑 process_backlog
=> RPS target CPU 的 /proc/softirqs NET_RX 计数增长
3. RPS 的使用
从前面的代码分析观察到，在函数 netif_receive_skb_internal() 有一个 if (static_key_false(&rps_needed)) 的条件判断，rps_needed 要通过哪里设置？这里我们不讨论内核代码实现细节，只指出 rps_needed 用户空间设置接口导出代码和功能。
/* net/core/net-sysfs.c */
static ssize_t store_rps_map(struct netdev_rx_queue *queue,
const char *buf, size_t len)
{
...
if (map)
static_key_slow_inc(&rps_needed);
if (old_map)
static_key_slow_dec(&rps_needed);
...
}
上面代码导出接口 /sys/class/net/<NIC>/queues/rx-N/rps_cpus，如：
# ls /sys/class/net/eth0/queues/rx-0/ -l
total 0
-rw-r--r-- 1 root root 4096 Sep 19 17:57 rps_cpus
-rw-r--r-- 1 root root 4096 Sep 19 23:06 rps_flow_cnt
其作用是 RPS 派发 skb 目标 CPU 集合的掩码，如 RPS 派发 skb 到 CPU 0~3，则可以设置为：
echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus
/* net/core/sysctl_net_core.c */
#ifdef CONFIG_RPS
static int rps_sock_flow_sysctl(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t *ppos)
{
...
if (write) {
...
if (sock_table != orig_sock_table) {
...
if (sock_table) {
static_key_slow_inc(&rps_needed);
static_key_slow_inc(&rfs_needed);
}
if (orig_sock_table) {
static_key_slow_dec(&rps_needed);
static_key_slow_dec(&rfs_needed);
synchronize_rcu();
vfree(orig_sock_table);
}
}
}
...
}
#endif /* CONFIG_RPS */
上面代码导出接口 /proc/sys/net/core/rps_sock_flow_entries，该接口设置 RPS 全局流表条目数，相对于 /sys/class/net/<NIC>/queues/rx-N/rps_flow_cnt 每队列的流表条目数。
关于 RPS 更多配置的细节，看参考 Linux 内核官方文档：Scaling in the Linux Networking Stack。
给出两组 RPS 功能的实测数据，测试上下文为 H3 / Linux 4.14.111 / stmmac / 100M Ethernet，测试对比了开启和关闭 RPS 前后，softirq 在 CPU 上的分布有了明显变化。
3.1 测试 1
- • H3 iperf3 server 一侧负责接收数据，将以太网中断放到 CPU 1，RPS 的目标 CPU 设为 2,3
# eth0 IRQ 保持 CPU1
echo 2 > /proc/irq/41/smp_affinity
# 开 RPS，把 RX 协议栈处理分到 CPU2/3
echo c > /sys/class/net/eth0/queues/rx-0/rps_cpus
iperf3 -s --one-off
- • Ubuntu iperf3 client 主机一侧发送流量数据
lxj@lxj-vm:~/Work$ iperf3 -c 192.168.1.230 -t 60
Connecting to host 192.168.1.230, port 5201
[ 5] local 192.168.1.188 port 48848 connected to 192.168.1.230 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 13.8 MBytes 116 Mbits/sec 0 597 KBytes
...
[ 5] 59.00-60.00 sec 11.2 MBytes 94.4 Mbits/sec 0 1.96 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.00 sec 676 MBytes 94.5 Mbits/sec 0 sender
[ 5] 0.00-60.17 sec 675 MBytes 94.1 Mbits/sec receiver
iperf Done.
对比测试前后硬件、软件中断统计，结果显示，以太网中断在 CPU 1 上增长，softirq 处理被 RPS 派发到 CPU 2,3：
root@NanoPi-NEO-Core:~# cat /data/netirq/rps-cpu23-before-interrupts.txt
CPU0 CPU1 CPU2 CPU3
...
41: 711722 494401 0 0 GICv2 114 Level eth0
...
IPI3: 117 197 225 226 Function call interrupts
...
root@NanoPi-NEO-Core:~# cat /data/netirq/rps-cpu23-before-softirqs.txt
CPU0 CPU1 CPU2 CPU3
...
NET_RX: 719951 499608 8308 3458
...
root@NanoPi-NEO-Core:~#
root@NanoPi-NEO-Core:~#
root@NanoPi-NEO-Core:~# cat /data/netirq/rps-cpu23-after-interrupts.txt
CPU0 CPU1 CPU2 CPU3
...
41: 711722 988274 0 0 GICv2 114 Level eth0
...
IPI3: 117 197 240 490204 Function call interrupts
...
root@NanoPi-NEO-Core:~#
root@NanoPi-NEO-Core:~#
root@NanoPi-NEO-Core:~# cat /data/netirq/rps-cpu23-after-softirqs.txt
CPU0 CPU1 CPU2 CPU3
...
NET_RX: 719975 1483464 8427 493436
...
从统计数据看，CPU1 处理到 RPS 分发点为止（即 NET_RX softirq 增长）；而 CPU 2,3 处理 RPS 分发点之后的网络协议栈主体。CPU 3 处理包最多，其上增长的 IPI 中断（Function call interrupts）次数正好等于 NET_RX softirq 增长数，即：490204 - 226 == 493436 - 3458 == 489978。
3.2 测试 2
- • H3 iperf3 server 一侧负责接收数据，将以太网中断放到 CPU 1，RPS 的目标 CPU 设为 2,3
echo 2 > /proc/irq/41/smp_affinity
echo c > /sys/class/net/eth0/queues/rx-0/rps_cpus
iperf3 -s --one-off
- • Ubuntu iperf3 client 主机一侧发送流量数据
xj@lxj-vm:~/Work$ iperf3 -c 192.168.1.230 -t 60 -P 4
Connecting to host 192.168.1.230, port 5201
[ 5] local 192.168.1.188 port 55276 connected to 192.168.1.230 port 5201
[ 7] local 192.168.1.188 port 55288 connected to 192.168.1.230 port 5201
[ 9] local 192.168.1.188 port 55298 connected to 192.168.1.230 port 5201
[ 11] local 192.168.1.188 port 55300 connected to 192.168.1.230 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 2.84 MBytes 23.8 Mbits/sec 0 134 KBytes
[ 7] 0.00-1.00 sec 4.24 MBytes 35.5 Mbits/sec 0 208 KBytes
[ 9] 0.00-1.00 sec 2.60 MBytes 21.8 Mbits/sec 0 126 KBytes
[ 11] 0.00-1.00 sec 4.81 MBytes 40.4 Mbits/sec 0 226 KBytes
[SUM] 0.00-1.00 sec 14.5 MBytes 122 Mbits/sec 0
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.00 sec 162 MBytes 22.7 Mbits/sec 0 sender
[ 5] 0.00-60.69 sec 161 MBytes 22.3 Mbits/sec receiver
[ 7] 0.00-60.00 sec 179 MBytes 25.0 Mbits/sec 0 sender
[ 7] 0.00-60.69 sec 159 MBytes 22.0 Mbits/sec receiver
[ 9] 0.00-60.00 sec 161 MBytes 22.5 Mbits/sec 0 sender
[ 9] 0.00-60.69 sec 178 MBytes 24.6 Mbits/sec receiver
[ 11] 0.00-60.00 sec 183 MBytes 25.6 Mbits/sec 0 sender
[ 11] 0.00-60.69 sec 182 MBytes 25.2 Mbits/sec receiver
[SUM] 0.00-60.00 sec 686 MBytes 95.8 Mbits/sec 0 sender
[SUM] 0.00-60.69 sec 680 MBytes 94.1 Mbits/sec receiver
iperf Done.
对比测试前后硬件、软件中断统计，结果显示，以太网中断在 CPU 1 上增长，softirq 处理被 RPS 派发到 CPU 2,3，这次均匀了，因为 iperf3 -P 4 开启多条数据流，RPS 会尽量保持同一条数据流在同一 CPU 上处理以保持 cache 热度（即 RPS 的优化: RFS）：
root@NanoPi-NEO-Core:~# cat /data/netirq/rps-p4-before-interrupts.txt
CPU0 CPU1 CPU2 CPU3
...
41: 711722 988285 0 0 GICv2 114 Level eth0
...
IPI3: 117 197 240 490215 Function call interrupts
...
root@NanoPi-NEO-Core:~# cat /data/netirq/rps-p4-before-softirqs.txt
CPU0 CPU1 CPU2 CPU3
...
NET_RX: 720815 1484130 9479 494671
...
root@NanoPi-NEO-Core:~# cat /data/netirq/rps-p4-after-interrupts.txt
CPU0 CPU1 CPU2 CPU3
...
41: 711722 1488906 0 0 GICv2 114 Level eth0
...
IPI3: 117 197 249680 737454 Function call interrupts
...
root@NanoPi-NEO-Core:~# cat /data/netirq/rps-p4-after-softirqs.txt
CPU0 CPU1 CPU2 CPU3
...
NET_RX: 721183 2481489 259144 741911
...
两组测试的结论：
- 1. IRQ affinity 后，eth0 IRQ 从 CPU0 迁移到 CPU1
- 2. 单 TCP flow + RPS CPU2/3 时，协议栈处理主要落到 CPU3
- 3. iperf3 -P 4 多 flow 时，CPU2/CPU3 的 NET_RX 都增长
另外：
- 1. /proc/softirqs 的 NET_RX 不是包数，而是该 CPU 执行 NET_RX_SOFTIRQ 的次数。
- 2. IRQ CPU 和 RPS target CPU 的 NET_RX 都会增长。
- 3. IRQ CPU 跑
stmmac_poll()/stmmac_rx()。 - 4. RPS target CPU 跑
process_backlog()/__netif_receive_skb_core()。
4. RPS 的优化: RFS
RPS 按 flow hash 选择 CPU，而不是按实时负载动态均衡（即 RPS 不是压力感知型 load balancer），而没有考虑 skb 目标接收进程读取 cache 命中率的问题，假设接收进程 A 运行在 CPU 0，而 RPS 出于 skb 在 CPU 上均衡考量，将目的地为进程 A 的 skb 派发了给 CPU 1 处理，则导致了进程 skb 内存的 cache miss，RFS(Receive Flow Steering) 功能就是让 RPS 考虑 CPU skb 均衡的同时，也考虑接收目的进程 cache 目中率的问题。
Linux 内核的配置文件 net/Kconfig 中的 CONFIG_RFS_ACCEL 配置项启用 RFS 功能：
config RFS_ACCEL
bool
depends on RPS
select CPU_RMAP
default y
CONFIG_RFS_ACCEL 是 Accelerated RFS，依赖硬件/驱动支持。从配置可以看到，配置项 CONFIG_RFS_ACCEL 依赖于 CONFIG_RPS，可见，RFS 是对 RPS 的增强。对 RFS 的实现细节，本文不做展开，感兴趣的读者可查询相关资料。
5. 小结
凡事都是利弊并存，RPS 虽然会把不同的数据流分到不同 CPU，但这也会增加 IPI 和跨 CPU skb 队列开销。
6. 参考资料
[1] Receive packet steering
[2] rps: Receive packet steering
[3] Scaling in the Linux Networking Stack
