作者：Zhao Gaofeng，AMD开发工程师，来源：AMD Xilinx开发者社区
本文介绍如何使能Linux网络协议栈中的RFS(receive flow steering)功能以优化MPSOC APU的并行处理能力，解决丢包问题。
问题描述：
在测试ZCU102 PL 10G Ethernet with MCDMA设计的性能时，遇到UDP接收丢包率很高的情况，测试使用的工具是iperf3。
测试过程：
Board side：在core1~3上各开一个iperf3 服务端用于收包，命令如下
iperf3 -s -p 5201 -A 1 &
iperf3 -s -p 5201 -A 2 &
iperf3 -s -p 5201 -A 3 &
server side：使用与zcu102用光纤相连的服务器发送UDP帧，命令如下
iperf3 -u -c 192.168.1.10 -p 5201 -i 60 -t 60 -b 800M -Z -T 5201 -l 1472 &
iperf3 -u -c 192.168.1.10 -p 5202 -i 60 -t 60 -b 800M -Z -T 5202 -l 1472 &
iperf3 -u -c 192.168.1.10 -p 5203 -i 60 -t 60 -b 800M -Z -T 5203 -l 1472 &
双方的网卡都工作在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，综上，执行命令如下：
echo 32768 > /proc/sys/net/core/rps_sock_flow_entries
echo 2048 > /sys/class/net/eth1/queues/rx-0/rps_flow_cnt
echo 2048 > /sys/class/net/eth1/queues/rx-1/rps_flow_cnt
echo 2048 > /sys/class/net/eth1/queues/rx-2/rps_flow_cnt
重新测试后结果如上图所示，丢包率大大降低，实际传输速度也达到了设定值，使用mpstat命令监控传输期间的CPU状况，发现CPU0的软中断占用时间降低，而CPU1~3的软中断占用升高，可以看出实现了负载的分配，但是从总体来看，四个CPU的总负载升高，说明RFS还是有一定的额外工作开销。
总结：
使用RFS可以一定程度上解决MPSOC 10G以太网应用(使用MCDMA时)中的UDP接收丢包问题，但是会产生额外的CPU开销，如果丢包率在接受范围内可以选择不开启。
