aboutgitcodebugslistschat
path: root/test
Commit message (Collapse)AuthorAgeFilesLines
* test: Allow sftp via vsock-ssh in testsDavid Gibson2024-05-021-2/+4
| | | | | | | | | | During some debugging recently, I wanted to extact a file from a test guest and found it was tricky, since the ssh-over-vsock setup we had didn't allow sftp/scp. We can fix this by adding a line to the guest side sshd config from mbuto. While we're there correct an inaccurate comment. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test: Make log truncation test more robustDavid Gibson2024-04-251-2/+3
| | | | | | | | | | | | | | | | | | | | | | | test/pasta_options/log_to_file checks that pasta truncates its log file when started. It does that by starting pasta with a log file once, then starting it again and checking that after the second round, the log file has only one line: the startup banner from the second invocation. However, this test will break if the second invocation logs any additional messages at startup. This can easily happen on a host with multiple network interfaces due to the "Multiple default route" informational messages added in 639fdf06e ("netlink: Fix selection of template interface"). I believe it could also happen on a host without IPv6 connectivity due to the "Couldn't pick external interface" messages, though I haven't confirmed this. Make the log file test more robust, by not testing for a single line, but instead explicitly testing for the PID of the second pasta invocation in the banner line. Link: https://bugs.passt.top/show_bug.cgi?id=88 Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test: Slight simplification to pasta log testsDavid Gibson2024-04-251-6/+2
| | | | | | | | | | | | | test/pasta_options/log_to_file contains a couple of rudimentary tests where we start pasta with an interactive shell, then immediately exit it. We can achieve the same thing by using /bin/true as the command to pasta. This also means that waiting for pasta to start, waiting for the executed command to complete and for pasta to clean up are all handled by simply waiting for pasta to complete in the foreground, so there's no need for an additional sleep. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test: Verify that podman tests are using the pasta binary we expect2024_04_05.954589bDavid Gibson2024-04-051-2/+9
| | | | | | | | | | | | Paul Holzinger pointed out that when we invoke the podman tests inside the passt testsuite, the way we point podman at the newly built pasta binary is kind of indirect. It's therefore prudent to check that podman is actually using the binary we expect it to - in particular that it is using the binary built in this tree, not some system installed pasta binary. Suggested-by: Paul Holzinger <pholzing@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test: catatonit may not be in $PATHDavid Gibson2024-04-051-1/+1
| | | | | | | | | | | | | The pasta_podman/bats test script looks for 'catatonit' amongst other tools to be avaiiliable on the host. However, while the podman tests do require catatonit, it doesn't necessarily need to be in the regular path. For example Fedora and RHEL place catatonit in /usr/libexec and podman finds it there fine. Therefore, remove it as an htools dependency. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test: Build and download podman as a test assetDavid Gibson2024-04-053-6/+13
| | | | | | | | | | | | | | | | | | | | | The pasta_podman/bats test scrpt downloads and builds podman, then runs its pasta specific tests. Downloading from within a test case has some drawbacks: * It can be very tedious if you have poor connectivity to the server * It makes a test that's ostensibly for pasta itself dependent on the state of the github server * It precludes runnning the tests in an isolated network environment The same concerns largely apply to building podman too, because it's pretty common for Go builds to download dependencies themselves. Therefore move the download and build of podman from the test itself, to the Makefile where we prepare other test assets. To avoid cryptic failures if something went wrong with the build, make running the test dependent on having the built podman binary. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test: Make sure to update mbuto repositoryDavid Gibson2024-04-051-1/+7
| | | | | | | | | We download and use mbuto to build trivial boot images for our VM tests. However, if mbuto is already cloned, we won't update it to the current version. Add some make logic to ensure that we do this. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test: Fix passt.mbuto for cases where /usr/sbin doesn't existDavid Gibson2024-01-161-1/+1
| | | | | | | | | | | | | | | | | f0ccca74 ("test: make passt.mbuto script more robust") is supposed to make mbuto more robust by standardizing on always putting things in /usr/sbin with /sbin a symlink to it. This matters because different distros have different conventions about how the two are used. However, the logic there requires that /usr/sbin at least exists to start with. This isn't always the case with Fedora derived mbuto images. Ironically the DIRS variable ensures that /sbin exists, although we then remove it, but doesn't require /usr/sbin to exist. Fix that up so that the new logic will work with Fedora. Fixes: f0ccca741f64 ("test: make passt.mbuto script more robust") Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test: make passt.mbuto script more robustJon Paul Maloy2023-12-271-1/+3
| | | | | | | | | | | Creation of a symbolic link from /sbin to /usr/sbin fails if /sbin exists and is non-empty. This is the case on Ubuntu-23.04. We fix this by removing /sbin before creating the link. Signed-off-by: Jon Maloy <jmaloy@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test: Select first reported IPv6 address for guest/host comparisonStefano Brivio2023-12-275-11/+11
| | | | | | | | | | | | | | | | | | | | If we run passt nested (a guest connected via passt to a guest connected via passt to the host), the first guest (L1) typically has two IPv6 addresses on the same interface: one formed from the prefix assigned via SLAAC, and another one assigned via DHCPv6 (to match the address on the host). When we select addresses for comparison, in this case, we have multiple global unicast addresses -- again, on the same interface. Selecting the first reported one on both host and guest is not entirely correct (in theory, the order might differ), but works reasonably well. Use the trick from 5beef085978e ("test: Only select a single interface or gateway in tests") to ask jq(1) for the first address returned by the query. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test: Make handling of shell prompts with escapes a little more reliableDavid Gibson2023-12-071-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | When using the old-style "pane" methods of executing commands during the tests, we need to scan the shell output for prompts in order to tell when commands have finished. This is inherently unreliable because commands could output things that look like prompts, and prompts might not look like we expect them to. The only way to really fix this is to use a better way of dispatching commands, like the newer "context" system. However, it's awkward to convert everything to "context" right at the moment, so we're still relying on some tests that do work most of the time. It is, however, particularly sensitive to fancy coloured prompts using escape sequences. Currently we try to handle this by stripping actual ESC characters with tr, then looking for some common variants. We can do a bit better: instead strip all escape sequences using sed before looking for our prompt. Or, at least, any one using [a-zA-Z] as the terminating character. Strictly speaking ANSI escapes can be terminated by any character in 0x40..0x7e, which isn't easily expressed in a regexp. This should capture all common ones, though. With this transformation we can simplify the list of patterns we then look for as a prompt, removing some redundant variants. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test: Avoid hitting guestfish command length limitsDavid Gibson2023-12-041-1/+1
| | | | | | | | | | | | | | | | In test/prepare-distro-img.sh we use guestfish to tweak our distro guest images to be suitable. Part of this is using a 'copy-in' directive to copy in the source files for passt itself. Currently we copy in all the files with a single 'copy-in', since it allows listing multiple files. However it turns out that the number of arguments it can accept is fairly limited and our current list of files is already very close to that limit. Instead, expand our list of files to one copy-in per file, avoiding that limitation. This isn't much slower, because all the commands still run in a single invocation of guestfish itself. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* valgrind: Adjust suppression for MSG_TRUNC with NULL bufferDavid Gibson2023-11-191-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | valgrind complains if we pass a NULL buffer to recv(), even if we use MSG_TRUNC, in which case it's actually safe. For a long time we've had a valgrind suppression for this. It singles out the recv() in tcp_sock_consume(), the only place we use MSG_TRUNC. However, tcp_sock_consume() only has a single caller, which makes it a prime candidate for inlining. If inlined, it won't appear on the stack and valgrind won't match the correct suppression. It appears that certain compiler versions (for example gcc-13.2.1 in Fedora 39) will inline this function even with the -O0 we use for valgrind builds. This breaks the suppression leading to a spurious failure in the tests. There's not really any way to adjust the suppression itself without making it overly broad (we don't want to match other recv() calls). So, as a hack explicitly prevent inlining of this function when we're making a valgrind build. To accomplish this add an explicit -DVALGRIND when making such a build. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test/lib/perf_report: Fix up table highlight for pasta's local flowsStefano Brivio2023-11-101-1/+9
| | | | | | | | | As commit 29269705239f ("test/perf: Small MTUs for spliced TCP aren't interesting") drops all columns for TCP test MTUs except for one, in throughput test for pasta's local flows, the first column we need to highlight in that table is now the second one. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test/perf: Simplify calculation of "omit" time for TCP throughputDavid Gibson2023-11-072-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the TCP throughput tests, we use iperf3's -O "omit" option which ignores results for the given time at the beginning of the test. Currently we calculate this as 1/6th of the test measurement time. The purpose of -O, however, is to skip over the TCP slow start period, which in no way depends on the overall length of the test. The slow start time is roughly speaking log_2 ( max_window_size / MSS ) * round_trip_time These factors all vary between tests and machines we're running on, but we can estimate some reasonable bounds for them: * The maximum window size is bounded by the buffer sizes at each end, which shouldn't exceed 16MiB * The mss varies with the MTU we use, but the smallest we use in tests is ~256 bytes * Round trip time will vary with the system, but with these essentially local transfers it will typically be well under 1ms (on my laptop it is closer to 0.03ms) That gives a worst case slow start time of about 16ms. Setting an omit time of 0.1s uniformly is therefore more than enough, and substantially smaller than what we calculate now for the default case (10s / 6 ~= 1.7s). This reduces total time for the standard benchmark run by around 30s. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test/perf: Remove unnecessary --pacing-timer optionsDavid Gibson2023-11-072-3/+3
| | | | | | | | | | We always set --pacing-timer when invoking iperf3. However, the iperf3 man page implies this is only relevant for the -b option. We only use the -b option for the UDP tests, not TCP, so remove --pacing-timer from the TCP cases. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test/perf: "MTU" changes in passt_tcp host to guest aren't usefulDavid Gibson2023-11-071-29/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* test/perf: Explicitly control UDP packet length, instead of MTUDavid Gibson2023-11-072-94/+75
| | | | | | | | | | | | | | | | | | | | | Packet size can make a big difference to UDP throughput, so it makes sense to measure it for a variety of different sizes. Currently we do this by adjusting the MTU on the relevant interface before running iperf3. However, the UDP packet size has no inherent connection to the MTU - it's controlled by the sender, and the MTU just affects whether the packet will make it through or be fragmented. The only reason adjusting the MTU works is because iperf3 bases its default packet size on the (path) MTU. We can test this more simply by using the -l option to the iperf3 client to directly control the packet size, instead of adjusting the MTU. As well as simplifying this lets us test different packet sizes for host to ns traffic. We couldn't do that previously because we don't have permission to change the MTU on the host. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test/perf: Small MTUs for spliced TCP aren't interestingDavid Gibson2023-11-071-52/+1
| | | | | | | | | | | | | | | | | | | | | | | 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>
* test/perf: Start iperf3 server less oftenDavid Gibson2023-11-075-109/+213
| | | | | | | | | | | | | | | | | | | 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: Get iperf3 stats from client sideDavid Gibson2023-11-071-18/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | iperf3 generates statistics about its run on both the client and server sides. They don't have exactly the same information, but both have the pieces we need (AFAICT the server communicates some nformation to the client over the control socket, so the most important information is in the client side output, even if measured by the server). Currently we use the server side information for our measurements. Using the client side information has several advantages though: * We can directly wait for the client to complete and we know we'll have the output we want. We don't need to sleep to give the server time to write out the results. * That in turn means we can wrap up as soon as the client is done, we don't need to wait overlong to make sure everything is finished. * The slightly different organisation of the data in the client output means that we always want the same json value, rather than requiring slightly different onces for UDP and TCP. The fact that we avoid some extra delays speeds up the overal run of the perf tests by around 7 minutes (out of around 35 minutes) on my laptop. The fact that we no longer unconditionally kill client and server after a certain time means that the client could run indefinitely if the server doesn't respond. We mitigate that by setting 1s connect timeout on the client. This isn't foolproof - if we get an initial response, but then lose connectivity this could still run indefinitely, however it does cover by far the most likely failure cases. --snd-timeout would provide more robustness, but I've hit odd failures when trying to use it. 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>
* test: Add Podman system test with bats for pasta2023_09_07.ee58f37Stefano Brivio2023-09-073-2/+27
| | | | | | | | | | | | | | | | | | | Ugly as hell, but we keep breaking things otherwise, and I keep forgetting to run this manually (as long as it's based on my local Podman setup, that's the only alternative). We need to clone the Podman repository as distribution packages don't contain test scripts, typically. While at it, build the latest version which is what really matters. As we're planning anyway to revamp the test framework, I'd be inclined to just add this without too many thoughts, and have it as a nice-to-have requirement reminder for the new framework. Link: https://github.com/containers/podman/pull/19699 Suggested-by: Paul Holzinger <pholzing@redhat.com> Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
* test/nstool: Fix fd leak in accept() loopDavid Gibson2023-05-231-0/+2
| | | | | | | | | nstool loops on accept(), but failed to close the accepted socket fds before continuing on. So, with repeated commands it would eventually die with an EMFILE. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test/nstool: Provide useful error if given a path that's too longDavid Gibson2023-05-231-8/+14
| | | | | | | | | | | | | Normal filesystem paths can be very long (PATH_MAX is around 8k), however Unix domain sockets can only use relatively short paths (UNIX_PATH_MAX is 108 on Linux). Currently nstool will simply truncate paths that are too long, leading to difficult to understand failures. Make such failures clearer, with an explicit error message if given a path that's too long. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* nstool: Enter holder's cwd when changing mount ns with nstool execDavid Gibson2023-04-081-1/+11
| | | | | | | | | | If we enter a mount namespace with nstool exec our working directory will be changed to / in the new mount ns. This is surprising if we haven't actually altered any mounts yet in the new ns. Instead, change the working directory to match that of the holder process in this situation. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* nstool: Advertise the holder's cwd (in its mountns) across the socketDavid Gibson2023-04-081-0/+4
| | | | | | | | This is possible useful in nstool info and has further uses for nstool exec. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test: Use "nstool exec" to slightly simplify testsDavid Gibson2023-04-083-26/+23
| | | | | | | | Using this, rather than using "nstool info" to get the pid then manually connecting with nsenter makes things a little simpler. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test: Initialise ${TRACE} properlyDavid Gibson2023-04-081-0/+3
| | | | | | | | | | Unlike ${DEBUG} we don't initialize ${TRACE} to 0 if not set, which cases failures when testing it later. That failure acts as though it is false, however it emits spurious errors in script.log, which can make it harder to spot real errors. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* nstool: Add --keep-caps option to nstool execDavid Gibson2023-04-081-9/+78
| | | | | | | | This allows you to run commands within a user namespace with the privilege that comes from owning that userns. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* nstool: Add nstool exec command to execute commands in an nstool namespaceDavid Gibson2023-04-081-2/+137
| | | | | | | | | This combines nstool info -pw <sock> with nsenter with various options for a more convenient and less verbose of entering existing nstool managed namespaces. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* nstool: Helpers to iterate through namespace typesDavid Gibson2023-04-081-10/+12
| | | | | | | Will make things a bit less verbose in future. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* nstool: Add magic number to advertized informationDavid Gibson2023-04-081-0/+9
| | | | | | | | So that we'll probably give a better error if you point it at something that's not an nstool hold control socket. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* nstool: Detect what namespaces target is inDavid Gibson2023-04-081-14/+143
| | | | | | | | | | Give nstool the ability to detect what namespaces the target process is in, relative to where it's called. That is, those namespace types for which the target is not in the same namespace as the caller. For now, just print this information with "info", which can be useful for debugging. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* nstool: Replace "pid" subcommand with "info" subcommandDavid Gibson2023-04-082-17/+55
| | | | | | | | | The new subcommand gives more information about the holder process and its namespace, and may be further extended in future. Add some options which give the old behaviour for existing scripts. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* nstool: Split some command line parsing and socket setup to subcommandsDavid Gibson2023-04-081-34/+68
| | | | | | | | This will make it easier to differentiate the options to those commands further in future. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* nstool: Move description of its operation modes from comment to usageDavid Gibson2023-04-081-15/+11
| | | | | | | Easier to see it there. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* nstool: Reverse parameters to nstoolDavid Gibson2023-04-082-28/+28
| | | | | | | | Having the "subcommand" first is more conventional and will make it more natural for future extensions I have planned. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* nstool: Rename nsholder to nstoolDavid Gibson2023-04-084-29/+29
| | | | | | | In preparation for extending what it does. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test: Remove race between commands run in the same contextDavid Gibson2023-04-081-2/+2
| | | | | | | | | | | | | context_run() has a race condition if two commands are run in close proximity (generally involving at least one in the background). Because we always use the same name for the temporary fifo files, if another command is issued while the fifos for the first still exist, mkfifo will fail, typically causing the entire test script to jam. Create unique names for the temporary fifos to avoid this problem. 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-0647-47/+47
| | | | | | | | | | | | | | | | | | | 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: Fedora 32-35 have moved to the archivesDavid Gibson2023-02-141-4/+4
| | | | | | | | Fedora 32-35 are now old enough that they're not on all mirrors. Fetch them from the archive server instead. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test: Update location for Debian ppc64 imagesDavid Gibson2023-02-142-2/+5
| | | | | | | | The current debian cloud images no longer include ppc64. Change to using the latest snapshot which does include ppc64. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test/pasta_options: Ignore failures on shell 'exit'Stefano Brivio2023-02-131-3/+6
| | | | | | | | | | | | | | | | | | | | On shell 'exit' commands, running shells from pasta, we might get: Cannot set tty process group (No such process) as some TTY devices might be unaccessible. This is harmless, but after commit "pasta: propagate exit code from child command", we'll get test failures there, at least with dash. Ignore those explicitly with a ugly workaround: we can't simply do something like: exit || : because the failure is reported by the shell itself once it exits, regardless of the command evaluation. 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/lib/test: Clean up iperf3 JSON files before starting the serverStefano Brivio2022-11-161-2/+2
| | | | | | | | ...instead of doing it after the test. Now that we have pre-built guest images, we might also have old JSON files from previous, interrupted test runs. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* test/memory/passt: Change passt.avx2 path to /bin in test itself2022_11_04.e308018Stefano Brivio2022-11-041-2/+2
| | | | | | | | Now that we install the binary in /bin, and we have a link from /usr/bin, change the path in the test itself as well. Otherwise it works with bash but not with dash for some reason. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* 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: Switch to qemu -netdev stream option instead of using qrapStefano Brivio2022-11-047-77/+75
| | | | | | | | | | | qemu commit 13c6be96618c ("net: stream: add unix socket") introduces support for native AF_UNIX support, finally making qrap useless. We can't quite drop that yet until a qemu release includes it, and then we'll need to wait a while for users to switch anyway, but at least for tests, we can use that support. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-03 08:18:59 +0000