On 2021/8/19 6:05, David Ahern wrote:
On 8/17/21 9:32 PM, Yunsheng Lin wrote:
This patchset adds the socket to netdev page frag recycling support based on the busy polling and page pool infrastructure.
The profermance improve from 30Gbit to 41Gbit for one thread iperf tcp flow, and the CPU usages decreases about 20% for four threads iperf flow with 100Gb line speed in IOMMU strict mode.
The profermance improve about 2.5% for one thread iperf tcp flow in IOMMU passthrough mode.
Details about the test setup? cpu model, mtu, any other relevant changes / settings.
CPU is arm64 Kunpeng 920, see: https://www.hisilicon.com/en/products/Kunpeng/Huawei-Kunpeng-920
mtu is 1500, the relevant changes/settings I can think of the iperf client runs on the same numa as the nic hw exists(which has one 100Gbit port), and the driver has the XPS enabled too.
How does that performance improvement compare with using the Tx ZC API? At 1500 MTU I see a CPU drop on the Tx side from 80% to 20% with the ZC API and ~10% increase in throughput. Bumping the MTU to 3300 and performance with the ZC API is 2x the current model with 1/2 the cpu.
I added a sysctl node to decide whether pfrag pool is used: net.ipv4.tcp_use_pfrag_pool
and use msg_zerocopy to compare the result: Server uses cmd "./msg_zerocopy -4 -i eth4 -C 32 -S 192.168.100.2 -r tcp" Client uses cmd "./msg_zerocopy -4 -i eth4 -C 0 -S 192.168.100.1 -D 192.168.100.2 tcp -"
The zc does seem to improve the CPU usages significantly, but not for throughput with mtu 1500. And the result seems to be similar with mtu 3300.
the detail result is below:
(1) IOMMU strict mode + net.ipv4.tcp_use_pfrag_pool = 0: root@(none):/# perf stat -e cycles ./msg_zerocopy -4 -i eth4 -C 0 -S 192.168.100.1 -D 192.168.100.2 tcp tx=115317 (7196 MB) txc=0 zc=n
Performance counter stats for './msg_zerocopy -4 -i eth4 -C 0 -S 192.168.100.1 -D 192.168.100.2 tcp':
4315472244 cycles
4.199890190 seconds time elapsed
0.084328000 seconds user 1.528714000 seconds sys root@(none):/# perf stat -e cycles ./msg_zerocopy -4 -i eth4 -C 0 -S 192.168.100.1 -D 192.168.100.2 tcp -z tx=90121 (5623 MB) txc=90121 zc=y
Performance counter stats for './msg_zerocopy -4 -i eth4 -C 0 -S 192.168.100.1 -D 192.168.100.2 tcp -z':
1715892155 cycles
4.243329050 seconds time elapsed
0.083275000 seconds user 0.755355000 seconds sys
(2)IOMMU strict mode + net.ipv4.tcp_use_pfrag_pool = 1: root@(none):/# perf stat -e cycles ./msg_zerocopy -4 -i eth4 -C 0 -S 192.168.100.1 -D 192.168.100.2 tcp tx=138932 (8669 MB) txc=0 zc=n
Performance counter stats for './msg_zerocopy -4 -i eth4 -C 0 -S 192.168.100.1 -D 192.168.100.2 tcp':
4034016168 cycles
4.199877510 seconds time elapsed
0.058143000 seconds user 1.644480000 seconds sys root@(none):/# perf stat -e cycles ./msg_zerocopy -4 -i eth4 -C 0 -S 192.168.100.1 -D 192.168.100.2 tcp -z tx=93369 (5826 MB) txc=93369 zc=y
Performance counter stats for './msg_zerocopy -4 -i eth4 -C 0 -S 192.168.100.1 -D 192.168.100.2 tcp -z':
1815300491 cycles
4.243259530 seconds time elapsed
0.051767000 seconds user 0.796610000 seconds sys
(3)IOMMU passthrough + net.ipv4.tcp_use_pfrag_pool=0 root@(none):/# perf stat -e cycles ./msg_zerocopy -4 -i eth4 -C 0 -S 192.168.100.1 -D 192.168.100.2 tcp tx=129927 (8107 MB) txc=0 zc=n
Performance counter stats for './msg_zerocopy -4 -i eth4 -C 0 -S 192.168.100.1 -D 192.168.100.2 tcp':
3720131007 cycles
4.200651840 seconds time elapsed
0.038604000 seconds user 1.455521000 seconds sys root@(none):/# perf stat -e cycles ./msg_zerocopy -4 -i eth4 -C 0 -S 192.168.100.1 -D 192.168.100.2 tcp -z tx=135285 (8442 MB) txc=135285 zc=y
Performance counter stats for './msg_zerocopy -4 -i eth4 -C 0 -S 192.168.100.1 -D 192.168.100.2 tcp -z':
1721949875 cycles
4.242596800 seconds time elapsed
0.024963000 seconds user 0.779391000 seconds sys
(4)IOMMU passthrough + net.ipv4.tcp_use_pfrag_pool=1 root@(none):/# perf stat -e cycles ./msg_zerocopy -4 -i eth4 -C 0 -S 192.168.100.1 -D 192.168.100.2 tcp tx=151844 (9475 MB) txc=0 zc=n
Performance counter stats for './msg_zerocopy -4 -i eth4 -C 0 -S 192.168.100.1 -D 192.168.100.2 tcp':
3786216097 cycles
4.200606520 seconds time elapsed
0.028633000 seconds user 1.569736000 seconds sys
Epyc 7502, ConnectX-6, IOMMU off.
In short, it seems like improving the Tx ZC API is the better path forward than per-socket page pools.
The main goal is to optimize the SMMU mapping/unmaping, if the cost of memcpy it higher than the SMMU mapping/unmaping + page pinning, then Tx ZC may be a better path, at leas it is not sure for small packet?
.