Linux RSS、RPS和RFS之间的主要区别是什么？

众所周知，有：

• 接收端缩放
• 接收数据包控制
• RFS：接收流控制

这是否意味着：

• RSS-允许我们使用多个CPU核来处理来自以太网的软irq（每个以太网队列一个CPU核）
• RPS-允许我们在同一个CPU核心上处理来自同一连接的所有数据包的软irq
• RFS-允许我们在同一个CPU核上处理来自同一连接的所有数据包的软irq，我们的应用程序线程在该CPU核上处理该连接

对吗？

引用自

• RSS：接收端扩展-是硬件实现的，并对数据包的某些字节进行散列（“网络和/或传输层头上的散列函数——例如，数据包IP地址和TCP端口上的4元组散列”）。实现是不同的，有些可能无法过滤最有用的字节，或者可能以其他方式受到限制。这种过滤和队列分布速度很快（在硬件中只需要几个额外的周期来分类数据包），但在某些网卡之间不可移植，或者不能用于隧道数据包或一些罕见的协议。有时，您的硬件不支持足够多的队列，无法为每个逻辑CPU核心获得一个队列

当延迟是一个问题时，或者在接收时，应该启用RSS 中断处理形成了瓶颈。在CPU之间分散负载 减少队列长度

• 接收数据包引导（RPS）”在逻辑上是 在软件中，它必须稍后在数据路径中调用。”。所以，当您使用没有RSS的硬件，或者希望基于比硬件更复杂的规则进行分类，或者使用无法在硬件RSS分类器中解析的协议时，这是硬件RSS的软件替代方案（仍然解析一些字节以将它们散列到队列id中）。但是使用RPS时，会使用更多的CPU资源，并且会产生额外的CPU间通信量

RPS比RSS有一些优势：1）它可以与任何NIC一起使用， 2） 软件过滤器可以很容易地添加到新协议的散列中， 3） 它不会增加硬件设备中断率（尽管它会 引入处理器间中断（IPI））

• RFS:Receive Flow Steering类似于RSS（具有更多CPU开销的软件机制），但它不只是散列到伪随机队列id中，而是考虑“应用程序位置”。（因此，由于良好的位置性，数据包处理可能会更快）。对队列进行跟踪，使其更接近将处理接收到的数据的线程，并将数据包传递到正确的CPU核心

RFS的目标是通过引导提高数据缓存命中率 内核将数据包处理到应用程序线程所在的CPU 正在运行数据包。RFS依赖于相同的RPS机制 将数据包排队到另一个CPU的待办事项上并唤醒该CPU 中央处理器。。。在RFS中，数据包不是通过其散列值直接转发的， 但散列用作流查找表的索引。这张桌子是地图 流到正在处理这些流的CPU

• 加速RFS-支持硬件的RFS。（检查您的网络驱动程序以了解

  ndo\u rx\u flow\u steer

  ）“加速RFS对于RFS就像RSS对于RPS：一种硬件加速负载平衡机制，它使用软状态根据消耗每个流的数据包的应用程序线程运行的位置来控制流。”

---

数据包传输的类似方法（但数据包已经生成并准备好发送，只需选择最佳队列即可发送数据包，并简化后处理，如释放skb）

• XPS:Transmit Packet Steering：“从CPU到硬件队列的映射是 此映射的目标通常是分配队列 专用于CPU的一个子集，其中 这些队列在此集合中的CPU上处理“

---

osgx的回答涵盖了主要的区别，但需要指出的是，RSS和RPS也可以同时使用

RSS控制用于接收数据包流的选定HW队列。一旦满足某些条件，将向SW发出中断。中断处理程序由NIC的驱动程序定义，是处理接收到的数据包的软件起点。那里的代码将轮询来自相关接收队列的数据包，可能执行初始处理，然后将数据包移动到更高级别的协议处理

此时，如果配置了RPS机制，则可以使用RPS机制。驱动程序调用netif_receive_skb（），它（最终）将检查RPS配置。如果存在，它将使SKB排队，以便在所选CPU上继续处理：

int netif_receive_skb(struct sk_buff *skb)
{
        ...
        return netif_receive_skb_internal(skb);
}

static int netif_receive_skb_internal(struct sk_buff *skb)
{
        ...
                int cpu = get_rps_cpu(skb->dev, skb, &rflow);

                if (cpu >= 0) {
                        ret = enqueue_to_backlog(skb, cpu, &rflow->last_qtail);
                        rcu_read_unlock();
                        return ret;
                }
        ...
}

在某些场景中，为了避免接收端的CPU利用率瓶颈，将RSS和RPS一起使用是明智的。IPoIB（Infiniband上的IP）就是一个很好的例子。IPoIB没有太多细节，它的模式只能打开一个通道。这意味着所有传入的流量将由单个核心处理。通过正确配置RPS，一些处理负载可以由多个内核共享，这大大提高了此场景的性能

由于提到了传输，值得注意的是，接收过程（ACK、转发）产生的数据包传输将从netif_receive_skb（）选择的同一核心进行处理

希望这有帮助。

谢谢！也就是说，如果RPS开启，则软IRQ将排队等待积压，并可在远程CPU核心上处理，但如果RPS关闭，则数据包将使用

\u netif\u receive\u skb（）{…\u netif\u receive\u skb\u Core（）}立即在同一CPU核心上处理，这是否意味着“IPoIB只能打开一个通道”，IPoIB只有一个rx队列还是其他什么？那么你呢