RPS/RFS简介

RPS/RFS是linux内核2.6版本中google工程师提交的两个patch，意在提升服务器负载能力。此功能主要为服务器服务，增加服务器各核心的负载均衡，优化服务器吞吐量。但是在移动设备中也可以引入此功能提升手机在进行大型游戏时，由于某几个cpu繁忙而无法及时处理网络数据的终端导致的高延时。

由于RPS只是单纯把数据包均衡到不同的cpu，这个时候如果应用程序所在的cpu和软中断处理的cpu不是同一个，此时对于cpu cache的影响会很大，那么RFS（Receive flow steering）确保应用程序处理的cpu跟软中断处理的cpu是同一个，这样就充分利用cpu的cache，这两个补丁往往都是一起设置，来达到最好的优化效果, 主要是针对单队列网卡多CPU环境。

配置方法

配置如下参数即可启用rps/rfs功能：

------------------------------------------------------

echo ff > /sys/class/net//queues/rx-*/rps_cpus

echo 4096 > /sys/class/net/queues/rx-*/rps_flow_cnt

---------------------------------------------------------------

8核的机器为ff，具体计算方法是第一颗cpu是00000001，第二个cpu是00000010，第3个cpu是 00000100。设置为0表示不支持此功能。

rps_flow_cnt就是RFS，表示当前网络设备rps队列的流表数，需要设置为2的整数次幂，建议设置为4096。数值越大，同时所能处理的rps流越多。

内核解释如下：

RPS原理

流程对比

开启RPS/RFS后，网络数据接收流程对比：

从流程中可以看出，相比传统的被中断cpu处理数据包变为中断cpu将数据存入backlog，等待rps实现的软中断自行分配到映射到的cpu处理，进而交付给报文所属app正在运行的cpu处理。

代码实现

当新的数据到来，内核调用如下序列：

Hdd_rx_deliver_to_stack

    ->netif_receive_skb

        ->netif_receive_skb_internal

get_rps_cpu函数主要是为了返回为处理报文配置的cpu，确保此报文将来会被期望的cpu执行处理。

sock_flow_table是保存在内中种的一张全局的hash表，用于映射socket和cpu。这里是保证了软中断会发生在应用期望的cpu核心上。flow_table,这个是针对设备的，每个设备队列都含有一个rps_dev_flow_table结构(这个表主要是保存了上次处理相同链接上的skb所在的cpu),这个hash表中每一个元素包含了一个cpu id

接下来进行cpu选择，skb中对应的hash值和sock mask计算确认想要运行的cpu在配置的范围之内（很可能此skb想要运行在cpu6，但是我们只配置了cpu 0-3作为报文处理cpu）

Tcp（应用所在）和next_cp（上一次分配数据给了那个cpu，本次分配给下一个cpu）分别从sock_flow_table和rps_flow_table计算出来，都是表示此报文接下来被哪个cpu处理。如果两者产生冲突，需要判断一下注释中所说的情况。

1. tcpu未设置(等于RPS_NO_CPU）

2. tcpu是离线的

3. tcpu的input_queue_head大于rps_flow_table中的last_qtail 的话就调度这个skb到next_cpu(当前应用所在cpu负载过高，分配报文到其他空闲的cpu).而这里第三点input_queue_head大于rps_flow_table则说明在当前的dev flow table中的数据包已经发送完毕，否则的话为了避免乱序就还是继续使用tcpu。

Enqueye_to_backlog根据取得的softnet_data，防止数据到per-CPU(每个CPU维护一个per_cpu变量用于维持每个cpu运行时独立的上下文)维护的队列中。

Napi_schedule唤醒软中断。

软中断唤醒skb对应的cpu，处理数据backlog中的数据报文。之后进入BSD协议栈上报给用户空间。