Understanding Host Network Stack Overheads论文阅读笔记

news2025/1/11 2:18:27

RFS (Receive Flow Steering)

RFS（Receive flow steering）和 RPS 配合使用。RPS 试图在 CPU 之间平衡收包，但是没考虑数据的本地性问题，如何最大化 CPU 缓存的命中率。RFS 将属于相同 flow 的包送到相同的 CPU 进行处理，可以提高缓存命中率。

调优：打开 RFS

RPS 记录一个全局的 hash table，包含所有 flow 的信息。这个 hash table 的大小可以在 net.core.rps_sock_flow_entries：

$ sudo sysctl -w net.core.rps_sock_flow_entries=32768
1
其次，你可以设置每个 RX queue 的 flow 数量，对应着 rps_flow_cnt：

例如，eth0 的 RX queue0 的 flow 数量调整到 2048：

$ sudo bash -c 'echo 2048 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt' 1

aRFS (Hardware accelerated RFS，需要硬件支持)

Accelerated RFS，类似英特尔硬件的Flow Director机制，或者是不同的说法

Accelerated RFS 之于 RFS 相当于 RSS 之于 RPS。Accelerated RFS 在硬件上就可以选择正确的队列，随后触发该数据包所属流所在的 CPU 的中断。由此可见，如果想要在硬件上实现队列选择，我们需要一个从流到硬件队列的对应关系。

从上文可知，我们已经有了一个从流到 CPU 的映射关系，记录在 rps_dev_flow 表中。
然后，我们也有 CPU 和硬件队列的关系，通过 /proc/irq/<irq_num>/smp_affinity 进行配置。

在这里插入图片描述

每当 rps_dev_flow 表中的条目被更新，网络协议栈就会调用驱动中的 ndo_rx_flow_steer 函数来更新流到硬件队列的对应关系。

Accelerated RFS 需要在编译阶段使能 CONFIG_RFS_ACCEL，并且需要硬件和驱动的支持。此外，还需要使用 ethtool 设置 ntuple 过滤。其他的就不需要配置了。

Accelerated RFS 机制可以将数据包直接放在最终的 CPU 硬件队列上，所以性能应该是要比 RFS 高。因此，当硬件支持该选项，应该选择此机制。

RFS 可以用硬件加速，网卡和内核协同工作，判断哪个 flow 应该在哪个 CPU 上处理。这需要网卡和网卡驱动的支持。

如果你的网卡驱动里对外提供一个 ndo_rx_flow_steer 函数，那就是支持 RFS。

调优: 启用 aRFS

假如你的网卡支持 aRFS，你可以开启它并做如下配置：

打开并配置 RFS 内核中编译期间指定了 CONFIG_RFS_ACCEL 选项。Ubuntu kernel 3.13.0 是有的
打开网卡的 ntuple 支持。可以用 ethtool 查看当前的 ntuple 设置配置 IRQ（硬中断）中每个 RX 和 CPU
的对应关系

以上配置完成后，aRFS 就会自动将 RX queue 数据移动到指定 CPU 的内存，每个 flow 的包都会到达同一个 CPU，不需要你再通过 ntuple 手动指定每个 flow 的配置了。

作用是最大化数据本地性（data locality），以增加 CPU 处理网络数据时的缓存命中率。例如，考虑运行在 80 口的 web 服务器：

webserver 进程运行在 80 口，并绑定到 CPU 2
和某个 RX queue 关联的硬中断绑定到 CPU 2
目的端口是80 的 TCP 流量通过 ntuple filtering 绑定到 CPU 2
接下来所有到 80口的流量，从数据包进来到数据到达用户程序的整个过程，都由 CPU 2 处理
仔细监控系统的缓存命中率、网络栈的延迟等信息，以验证以上配置是否生效