AC9 96U及以上规格单虚拟机单向接收PPS，使用HCE2.0，接收PPS只有12M达不到预期

问题现象

AC9 96U及以上规格单虚拟机单向接收PPS，使用HCE2.0，接收PPS只有12M达不到预期。

操作步骤

1. ethtool -l eth0观测并记录被测试虚拟机的队列，流数与队列数持平。
2. server端虚拟机执行以下命令并根据打流模型确定server端启动iperf3监听进程数量 。
   • iperf3 -s -p 5001
   • iperf3 -s -p 5002

3. client端虚拟机执行以下命令:
   • iperf3 -c -b 100M -u -t 300 -l 64 -p 5001
   • iperf3 -c -b 100M -u -t 300 -l 64 -p 5002
   

   命令中-b 100m应当根据实际测试的虚拟机规格进行调整， -b 10m约为2万pps，可以根据此进行换算。比如-b 100m 单流基本可以打20万pps。 加压的pps与flavor限速基本持平为宜，这样能够准确测试出对应pps下的丢包和时延性能数据。

4. 命令全部启动后在server端使用sar -n dev 3 20查看接收pps在1分钟的平均值，测试5次求平均。
5. 打流同时使用ping serverip -c 120观测极限压力下虚拟机ping时延，测试5次求平均。
6. 打流同时使用ping -i 0.01 serverip -c 10000观测极限压力下虚拟机丢包，测试5次求平均。

预期结果

达到flavor qos。

实际结果

测试只有12M

根本原因

• virtio_net驱动最开始未使用high order，就是order0页面。
• 社区优化skb使用了order3页面，请参考：https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5640f7685831
• virtio_net引入skb_page_frag_refill也使用order3。
• 社区添加high order开关关闭order3，解决使能order3时页面锁竞争问题，提升高并发场景下性能，低并发场景下（并发数小于8）有影响。请参考：https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ce27ec60648d8e066227cb2f58b1d3d4f7253d08。

最终结果

测试只有12M，使用镜像的规避方法规避后，可以达到20M。

规避方法：sysctl -w net.core.high_order_alloc_disable=1。