问题描述:

在测试 ZCU102 PL 10G Ethernet with MCDMA 设计的性能时，遇到 UDP 接收丢包率很高的情况，测试使用的工具是 iperf3。

测试过程：

Board side：在 core1~3 上各开一个 iperf3 服务端用于收包，命令如下:

Server side：使用与 zcu102 用光纤相连的服务器发送 UDP 帧，命令如下:

双方的网卡都工作在 MTU1500 模式下，故数据段长度设为 1472B，总带宽暂设为 2400M。

测试结果如上图所示，丢包率超过了百分之十，故实际传输速度也达不到设定的带宽，使用 mpstat 命令观察 CPU 使用状况，发现接收工程中 CPU0 的软中断占用达到93.3%。

解决方案：

使用 RFS 接收流导向，RFS 是 Linux 网络协议栈提供的一项辅助性功能，RFS 的目标是通过将数据包在内核中的处理引导到使用该数据包的应用程序线程对应的 CPU 来提高数据缓存的命中率，详情可参考 Linux 内核文档https://www.kernel.org/doc/html/latest/networking/scaling.html

在本文的测试中 Board side 上运行了三个 iperf 服务端在三个 CPU 上，RFS 可以将发给某个服务端的数据包的部分处理工作交给这个服务端对应的 CPU 执行，以此平衡工作负载。 按照文档中的说明，rps_sock_flow_entries 设置为32768，本文使用的设计中 MCDMA 共有16个接收通道，所以 rps_flow_cnt 为32768/16=2048，另外共开启了三个 iperf 服务端，所以暂时只设置 rx-0~rx-2，综上，执行命令如下：

重新测试后结果如上图所示，丢包率大大降低，实际传输速度也达到了设定值，使用 mpstat 命令监控传输期间的 CPU 状况，发现 CPU0 的软中断占用时间降低，而 CPU1~3 的软中断占用升高，可以看出实现了负载的分配，但是从总体来看，四个 CPU 的总负载升高，说明 RFS 还是有一定的额外工作开销。  

总结：

使用 RFS 可以一定程度上解决 MPSoC 10G 以太网应用(使用 MCDMA 时)中的 UDP 接收丢包问题，但是会产生额外的 CPU 开销，如果丢包率在接受范围内可以选择不开启。