passt/test/lib, branch 2024_06_24.1ee2eca

test: Make handling of shell prompts with escapes a little more reliable

2023-12-07T06:24:48+00:00

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 
Signed-off-by: Stefano Brivio

test/lib/perf_report: Fix up table highlight for pasta's local flows

2023-11-10T05:35:54+00:00

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

test/perf: Start iperf3 server less often

2023-11-07T08:56:10+00:00

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 
Signed-off-by: Stefano Brivio

test/perf: Get iperf3 stats from client side

2023-11-07T08:56:06+00:00

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 
Signed-off-by: Stefano Brivio

test: Use "nstool exec" to slightly simplify tests

2023-04-07T23:12:08+00:00

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 
Signed-off-by: Stefano Brivio

nstool: Replace "pid" subcommand with "info" subcommand

2023-04-07T23:11:52+00:00

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 
Signed-off-by: Stefano Brivio

nstool: Reverse parameters to nstool

2023-04-07T23:11:43+00:00

Having the "subcommand" first is more conventional and will make it more
natural for future extensions I have planned.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

nstool: Rename nsholder to nstool

2023-04-07T23:11:41+00:00

In preparation for extending what it does.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

test: Remove race between commands run in the same context

2023-04-07T23:11:36+00:00

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 
Signed-off-by: Stefano Brivio

passt: Relicense to GPL 2.0, or any later version

2023-04-06T16:00:33+00:00

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