passt/test/perf
David Gibson 498108ad70 test/perf: "MTU" changes in passt_tcp host to guest aren't useful
The TCP packet size used on the passt L2 link (qemu socket) makes a huge
difference to passt/pasta throughput; many of passt's overheads (chiefly
syscalls) are per-packet.

That packet size is largely determined by the MTU on the L2 link, so we
benchmark for a number of different MTUs.  That works well for the guest to
host transfers.  For the host to guest transfers, we purport to test for
different MTUs, but we're not actually adjusting anything interesting.

The host to guest transfers adjust the MTU on the "host's" (actually ns)
loopback interface.  However, that only affects the packet size for the
socket going to passt, not the packet size for the L2 link that passt
manages - passt can and will repack the stream into packets of its own
size.  Since the depacketization on that socket is handled by the kernel it
doesn't have a lot of bearing on passt's performance.

We can't fix this by changing the L2 link MTU from the guest side (as we do
for guest to host), because that would only change the guest's view of the
MTU, passt would still think it has the large MTU.  We could test this by
using the --mtu option to passt, but that would require restarting passt
for each run, which is awkward in the current setup.  So, for now, drop all
the "small MTU" tests for host to guest.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-11-07 09:56:18 +01:00
..
passt_tcp test/perf: "MTU" changes in passt_tcp host to guest aren't useful 2023-11-07 09:56:18 +01:00
passt_udp test/perf: Explicitly control UDP packet length, instead of MTU 2023-11-07 09:56:16 +01:00
pasta_tcp test/perf: Small MTUs for spliced TCP aren't interesting 2023-11-07 09:56:13 +01:00
pasta_udp test/perf: Explicitly control UDP packet length, instead of MTU 2023-11-07 09:56:16 +01:00