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

Question

众所周知，有：https://www.kernel.org/doc/Documentation/networking/scaling.txt

• RSS:接收侧缩放
• RPS:接收数据包引导
• RFS:接收流量转向

这是否意味着：

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

对吗？

Answer 1

引号来自https://www.kernel.org/doc/Documentation/networking/scaling.txt。

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

当延迟引起关注或接收中断处理形成瓶颈时，应该启用RSS。CPU之间的扩展负载减少了队列长度。

• 接收包控制(RPS)“在逻辑上是RSS的一个软件实现，在软件中，它必然在数据路径中被调用。”因此，这是硬件RSS的软件替代(当您使用没有RSS的硬件或希望基于比hw能够或没有在HW RSS分类器中不能解析的协议更复杂的规则进行分类时，仍然会解析一些字节以将它们散列到队列id中)。但是对于RPS，使用更多的CPU资源，并且有额外的CPU间通信量。

与RSS相比，RPS具有以下优点: 1)它可以用于任何NIC；2)软件过滤器可以很容易地添加到新协议的哈希中；3)它不增加硬件设备中断率(尽管它确实引入了处理器间中断(IPI))。

• RFS:接收流引导类似于RSS (具有更多CPU开销的软件机制)，但它不只是散列到伪随机队列id，而是“考虑到应用程序的局部性”。(因此，由于本地性好，数据包处理可能会更快)。队列被跟踪到将处理接收到的数据的线程中更本地，并将数据包传递到正确的CPU核心。

RFS的目标是通过将数据包的内核处理引导到应用程序线程正在运行的CPU来提高数据缓存命中率。RFS依靠相同的RPS机制将数据包排队到另一个CPU的待办事项上，并唤醒该CPU。..。在RFS中，数据包不是通过其哈希值直接转发的，而是将哈希用作流查找表中的索引。此表将流映射到正在处理这些流的CPU。

• 加速RFS与hw支持。(检查ndo_rx_flow_steer的网络驱动程序)“加速的RFS与RSS的关系就像RSS:一种硬件加速的负载平衡机制，它使用软状态来根据使用每个流的数据包的应用程序线程的位置来引导流。”

类似的数据包传输方法(但数据包已经生成并准备发送，只需选择最佳队列来发送-并且要更容易地进行后处理，比如释放skb)。

• XPS:传输包引导：“记录从CPU到硬件队列的映射。此映射的目标通常是将队列专门分配给CPU的子集，其中这些队列的传输完成是在这个集合内的CPU上处理的。”