diff options
| author | David Gibson <david@gibson.dropbear.id.au> | 2023-11-06 18:08:29 +1100 |
|---|---|---|
| committer | Stefano Brivio <sbrivio@redhat.com> | 2023-11-07 09:56:13 +0100 |
| commit | 29269705239fc3102a42950a5d84c3c3acd619d0 (patch) | |
| tree | d65c6381539f5e102902237c38542cd2b22e23ed /log.c | |
| parent | e516809a74ffd495481a7adf6b565181861a41f9 (diff) | |
| download | passt-29269705239fc3102a42950a5d84c3c3acd619d0.tar passt-29269705239fc3102a42950a5d84c3c3acd619d0.tar.gz passt-29269705239fc3102a42950a5d84c3c3acd619d0.tar.bz2 passt-29269705239fc3102a42950a5d84c3c3acd619d0.tar.lz passt-29269705239fc3102a42950a5d84c3c3acd619d0.tar.xz passt-29269705239fc3102a42950a5d84c3c3acd619d0.tar.zst passt-29269705239fc3102a42950a5d84c3c3acd619d0.zip | |
test/perf: Small MTUs for spliced TCP aren't interesting
Currently we make TCP throughput measurements for spliced connections with
a number of different MTU values. However, the results from this aren't
really interesting.
Unlike with tap connections, spliced connections only involve the loopback
interface on host and container, not a "real" external interface. lo
typically has an MTU of 65535 and there is very little reason to ever
change that. So, the measurements for smaller MTUs are rarely going to be
relevant.
In addition, the fact that we can offload all the {de,}packetization to the
kernel with splice(2) means that the throughput difference between these
MTUs isn't very great anyway.
Remove the short MTUs and only show spliced throughput for the normal
65535 byte loopback MTU. This reduces runtime of the performance tests on
my laptop by about 1 minute (out of ~24 minutes).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'log.c')
0 files changed, 0 insertions, 0 deletions