[VPP-1947] Simpler processing is less efficient with more workers
Description
This is not a new issue, but I probably have not opened a Jira ticket for this yet.
It seems simpler processing (tests with higher throughput when 1 core is used) start showing performance degradation, eventually reaching lower throughput (than other tests with similar but less simple processing) when multiple cores are used.
Example graphs from 2009 report: [0].
As far as I can tell, this affects all NICs (if the performance is not higher than hardware limits), all divers (RDMA, DPDK, AVF) and all architectures (they only differ in the amount of cores where the regression starts).
I have prepared a small test run [1], on Haswell as other testbeds are busy. Haswell is 3-node testbed (no hyperthreading), so outputs are from 2 VPP boxes, and traffic is not entirely symmetric on them (one directions has less packets, as some were already lost on the other box). I will collect more tests later.
L2patch is faster than l2bdbasemaclrn with 2 cores, but slower with 4 cores. It affects both MRR and NDR/PDR results. Both tests use the same traffic profile, only VPP configuration is different.
Looking at "show run" [2], there is some mismatch between *-output and *-tx nodes, but not big enough to explain the performance. Number of processed packets per cycle is low, so ideally no loss should happen.
Looking at statistics [3] after measurements, I see rx_dropped_packets large enough to explain the performance. But I see no good reason why RX buffers should get full with this small number of cycles per packets.
The only explanation I see is that more frequent polling somehow causes the packet loss (as if reading from RX queue applies a lock, preventing NIC from adding packets there). Is that possible? If yes, are there any recommended workarounds? If no, is there a bug in VPP to fix?
Assignee
Unassigned
Reporter
Vratko Polak
Comments
- vrpolak (Thu, 22 Feb 2024 15:26:43 +0000):
Some comparisons ([5] for 2n-spr AVF and [6] for 3n-tsh) from last release confirming this is still an issue.
- vrpolak (Mon, 24 Apr 2023 10:54:57 +0000): Recent example: A merge [9] into VPP causes multiple progressions, but also few regressions in trending [10].
[9] https://gerrit.fd.io/r/c/vpp/+/38452?forceReload=true
- vrpolak (Thu, 24 Feb 2022 12:26:34 +0000):
Adding links to runtime statistics after trial at PDR rate. Still for 2110 VPP, dpdk_plugin, l2-patch, but on 2n-skx.
This time there is no mismatch on tx, not rx misses, but still 4c [8] forwards less packets than 2c [7] (which forwards slightly more than 1c [6]).
- vrpolak (Tue, 16 Nov 2021 11:14:33 +0000):
This also affects testpmd on most architectures:
- vrpolak (Tue, 9 Nov 2021 14:44:40 +0000):
Still present, adding newer link to report (not officially released yet):
Original issue: https://jira.fd.io/browse/VPP-1947