aboutgitcodebugslistschat
path: root/test/perf
Commit message (Collapse)AuthorAgeFilesLines
* test/perf: Start iperf3 server less oftenDavid Gibson2023-11-074-90/+175
| | | | | | | | | | | | | | | | | | | Currently we start both the iperf3 server(s) and client(s) afresh each time we want to make a bandwidth measurement. That's not really necessary as usually a whole batch of bandwidth measurements can use the same server. Split up the iperf3 directive into 3 directives: iperf3s to start the server, iperf3 to make a measurement and iperf3k to kill the server, so that we can start the server less often. This - and more importantly, the reduced number of waits for the server to be ready - reduces runtime of the performance tests on my laptop by about 4m (out of ~28minutes). For now we still restart the server between IPv4 and IPv6 tests. That's because in some cases the latency measurements we make in between use the same ports. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test/perf: Remove stale iperf3c/iperf3s directivesDavid Gibson2023-11-072-6/+1
| | | | | | | | | | Some older revisions used separate iperf3c and iperf3s test directives to invoke the iperf3 client and server. Those were combined into a single iperf3 directive some time ago, but a couple of places still have the old syntax. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* passt: Relicense to GPL 2.0, or any later versionStefano Brivio2023-04-064-4/+4
| | | | | | | | | | | | | | | | | | | In practical terms, passt doesn't benefit from the additional protection offered by the AGPL over the GPL, because it's not suitable to be executed over a computer network. Further, restricting the distribution under the version 3 of the GPL wouldn't provide any practical advantage either, as long as the passt codebase is concerned, and might cause unnecessary compatibility dilemmas. Change licensing terms to the GNU General Public License Version 2, or any later version, with written permission from all current and past contributors, namely: myself, David Gibson, Laine Stump, Andrea Bolognani, Paul Holzinger, Richard W.M. Jones, Chris Kuhn, Florian Weimer, Giuseppe Scrivano, Stefan Hajnoczi, and Vasiliy Ulyanov. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test/perf/pasta_tcp: Add host to namespace cases for traffic via tapStefano Brivio2023-01-051-0/+57
| | | | | | | | | | Similarly to UDP cases, these were missing as it wasn't clear, when the other tests were introduced, if using the global address of a namespace, from the host, should have resulted in connections being routed via the tap interface. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
* test/perf/pasta_udp: Add host to namespace cases for traffic via tapStefano Brivio2023-01-051-0/+37
| | | | | | | | | | | | | | These were missing as it wasn't clear, when the other tests were introduced, if using the global address of a namespace, from the host, should have resulted in traffic being routed via the tap interface (as opposed to the loopback interface). We now clarified that's actually the case. Use same values and thresholds as the tests for loopback traffic, as throughput figures currently indicate there isn't much difference. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
* test/perf: Finally drop workaround for virtio_net TX stallStefano Brivio2022-11-042-30/+0
| | | | | | | | | | | | Now that we require 13c6be96618c ("net: stream: add unix socket") in qemu to run the tests, we can also assume that commit df8d07081718 ("virtio-net: fix bottom-half packet TX on asynchronous completion") is present, as it was merged before that one. This fixes the issue we attempted to work around in passt TCP and UDP performance tests: finally drop that stuff. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test/perf: Wait for neper servers in guest to be ready before starting clientStefano Brivio2022-09-232-0/+6
| | | | | | | | Starting tcp_rr, tcp_crr, udp_rr servers in the guest takes a bit longer than starting the corresponding clients on the host, and we end up starting clients before servers unless we add a delay there. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test/perf: Disable periodic throughput reports to avoid vhost hangStefano Brivio2022-09-224-4/+4
| | | | | | | | | | | | | | | | | | It appears that if we run throughput tests with one-second periodic reports, the sending side of the vhost channel used for SSH-based command dispatch occasionally stops working altogether. I haven't investigated this further, all I see is that output is truncated at some point, and doesn't resume. If we use gzip compression (ssh -C) this happens less frequently, but it still happens, seemingly indicating the issue is probably related to vhost itself. Disable periodic reports in iperf3 clients. The -i options were actually redundant, so remove them from both test files as well as from test_iperf3(). Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test/perf: Switch performance test duration to 10 seconds instead of 30Stefano Brivio2022-09-224-4/+4
| | | | | | | | | It looks like the workaround for the virtio_net TX hang issue is working less reliably with the new command dispatch mechanism, I'm not sure why. Switch to 10 seconds, at least for the moment. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
* test/perf: Always use /sbin/sysctl in tcp testStefano Brivio2022-09-222-6/+6
| | | | | Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
* test/perf: Check for /sbin/sysctl with which(1), not simply sysctlStefano Brivio2022-09-223-4/+4
| | | | | | | | | | Otherwise, we're depending on having /sbin in $PATH. For some reason I didn't completely grasp, with the new command dispatch mechanism that's not the case anymore, even if I have /sbin in $PATH in the parent shell. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
* test: Rewrite test_iperf3David Gibson2022-09-072-3/+3
| | | | | | | | | | | | | | | test_iperf3() is a pretty inscrutable mess of nested background processes. It has a number of ugly sleeps needed to wait for things to complete. Rewrite it to be cleaner: * Use the construct (a & b & wait) to run 'a' and 'b' in parallel, but then wait for them both to complete before continuing * This allows us to wait for both the server and client to finish, rather than sleeping * Use jq to do all the math we need to get the final result, rather than jq followed by some complicated 'bc' mangling Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* test: Parameterize run time for throughput performance testsDavid Gibson2022-09-074-83/+89
| | | | | | | | | | | | Currently all the throughput tests are run for 30s. This is reflected in both the actual parameters given to the iperf commands, but also in the matching sleeps in test_iperf3. Allow this to be adjusted more easily with a new parameter to test_iperf3. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> [sbrivio: Reflect new parameter in comment to test_iperf3()] Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test: Combine iperf3c and iperf3s into a single DSL commandDavid Gibson2022-09-074-150/+79
| | | | | | | | | | | | | | | | | These two commands in the DSL to run an iperf client and server are always used together, and some of the parameters must match between them. The iperf3s must also be run more or less immediately after iperf3c, since iperf3c will run a client in the background after a sleep and requires a server to be running before it will work. A bunch of things can be made cleaner if we make a single DSL command that runs both sides of the test. For now make the combined command work exactly like the two commands together did, warts and all. This does lose the ability for the DSL scripts to give additional options to the iperf3 server, but we weren't using that anyway. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* tests: Explicitly list test files in test/run, remove "onlyfor" supportDavid Gibson2022-07-144-4/+0
| | | | | | | | | | | | | | | | | Currently test/run uses wildcards to run all of the tests in a directory. However, that wildcard list is filtered down by the "onlyfor" directives in the test files... usually to a single file. Therefore, just explicitly list the files we *really* want to run for this test mode. This makes it easier to see at the top level what tests will be executed, and to change that list temporarily while debugging specific failures. This means the "onlyfor" directive no longer has any purpose, and we can remove it. "onlyfor" was also the only used of the $MODE variable, so we can remove that too. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* test: Embed script for dhclient(8) in mbuto(1) profileStefano Brivio2022-07-142-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | David reports that dhclient-script(8) on Fedora needs a number of binaries that are not included in PROGS of the current mbuto profile, and we would also need to include hostnamectl(1) there, which will fail without a systemd init. Embed a minimal script for dhclient(8) in the profile itself, written to /sbin/dhclient-script at boot, to just check what we need to check out of DHCP and DHCPv6 functionality. While at it, drop busybox and logger from PROGS, as we don't need them, and add hostname(1). While DHCP option 12 isn't supported yet by the DHCP implementation in passt, we should probably add it soon. Note: owing to the simplicity of this script, we now need to bring up the interface before starting dhclient: add this in test scripts where it's not the case yet. Reported-by: David Gibson <david@gibson.dropbear.id.au> Suggested-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com> note that we need to bring up the interface before starting dhclient
* Tweak dhclient arguments for readabilityDavid Gibson2022-06-152-2/+2
| | | | | | | | | | | | | | A number of tests and examples use dhclient in both IPv4 and IPv6 modes. We use "dhclient -6" for IPv6, but usually just "dhclient" for IPv4. Add an explicit "-4" argument to make it more clear and explicit. In addition, when dhclient is run from within pasta it usually won't be "real" root, and so will not have access to write the default global pid file. This results in a mostly harmless but irritating error: Can't create /var/run/dhclient.pid: Permission denied We can avoid that by using the --no-pid flag to dhclient. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* Don't abbreviate ip(8) arguments in examples and testsDavid Gibson2022-06-154-12/+12
| | | | | | | | ip(8)'s ability to take abbreviated arguments (e.g. "li sh" instead of "link show") is very handy when using it interactively, but it doesn't make for very readable scripts and examples when shown that way. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* test/perf/pasta_udp: Drop redundant assignment of ::1 to loopback interfaceStefano Brivio2022-05-191-1/+0
| | | | | | | | | | | There are a few occurrences of this assignment, which are needed to re-add ::1 as loopback address after the MTU has been increased back from a value below 1280 bytes. This one, however, is redundant, and causes an error in the execution. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test/perf: Work-around for virtio_net hang before long streams from guestStefano Brivio2022-03-292-0/+30
| | | | | | | I didn't have time to investigate the root cause for the virtio_net TX hang yet. Add a quick work-around for the moment being. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test/perf/passt_udp: Drop threshold for 256B testStefano Brivio2022-02-211-2/+2
| | | | | | | | | That test fails sometimes, it looks like iperf3 is still sending initial messages that are too big. I'll need to figure out why, but given that 256 bytes is not really an expected MTU, drop the thresholds to zero for the moment being. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test/perf/passt_tcp: Drop iperf3 window size for host-to-guest testsStefano Brivio2022-02-011-10/+10
| | | | | | | | | | With a recent 5.15 kernel, passing a huge window size to iperf3 with lower MTUs makes iperf3 stop sending packets after a few seconds -- I haven't investigated this in detail, but the window size will be adjusted dynamically anyway and not passing it doesn't actually affect throughput, so simply drop the option. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* perf/passt_udp: Lower failure throughput thresholds with big MTUsStefano Brivio2022-01-261-4/+4
| | | | | | | The throughput results in this test look quite variable, slightly lower figures look reasonable anyway. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test/perf: Actually load passt enough to test UDP performanceStefano Brivio2021-10-212-26/+26
| | | | | | | | | With recent improvements, we're not CPU-bound at all while testing UDP performance. Give the VM more memory and CPUs, forward two additional ports, start up to four threads in parallel, and give single iperf3 threads higher bandwidth targets. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test/perf: Try sourcing maximum scaling frequency from cpufreqStefano Brivio2021-10-214-4/+14
| | | | | | | On most recent CPUs, that's a better indication of all-core turbo frequency, or non-turbo frequency, than /proc/cpuinfo. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* perf/passt_udp: Don't overshoot UDP bandwidth excessively on larger MTUsStefano Brivio2021-10-191-2/+2
| | | | | | | ...performance with 64KiB MTUs might look worse than with 9000bytes on some configurations. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* perf/passt_tcp: Don't exceed typical L3 cache sizes with buffersStefano Brivio2021-10-191-8/+8
| | | | | | ...we might see misleading rate drops with larger MTUs otherwise. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test/perf: Use CPU frequency from /proc/cpuinfo instead of cpupower(1)Stefano Brivio2021-10-194-8/+8
| | | | | | Get it to work also in nested virtualisation environments. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test: Add CI/demo scriptsStefano Brivio2021-09-274-0/+859
Not really quick, definitely dirty. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>