<feed xmlns='http://www.w3.org/2005/Atom'>
<title>passt/test/perf/passt_udp, branch 2023_03_29.b10b983</title>
<subtitle>Plug A Simple Socket Transport</subtitle>
<link rel='alternate' type='text/html' href='https://passt.top/passt/'/>
<entry>
<title>test/perf: Finally drop workaround for virtio_net TX stall</title>
<updated>2022-11-04T11:04:32+00:00</updated>
<author>
<name>Stefano Brivio</name>
<email>sbrivio@redhat.com</email>
</author>
<published>2022-11-04T01:20:43+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=6c1697764ccd0ae0596fcad0ad5c8434430f8b23'/>
<id>6c1697764ccd0ae0596fcad0ad5c8434430f8b23</id>
<content type='text'>
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 &lt;sbrivio@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;sbrivio@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>test/perf: Wait for neper servers in guest to be ready before starting client</title>
<updated>2022-09-23T00:46:24+00:00</updated>
<author>
<name>Stefano Brivio</name>
<email>sbrivio@redhat.com</email>
</author>
<published>2022-09-22T14:40:28+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=1134ce88fe562dc2e95780a54835fae9eb9070f0'/>
<id>1134ce88fe562dc2e95780a54835fae9eb9070f0</id>
<content type='text'>
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 &lt;sbrivio@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;sbrivio@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>test/perf: Disable periodic throughput reports to avoid vhost hang</title>
<updated>2022-09-22T14:54:09+00:00</updated>
<author>
<name>Stefano Brivio</name>
<email>sbrivio@redhat.com</email>
</author>
<published>2022-09-20T23:21:32+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=df29ebfe02aa0639278527b0fa2d90074263af0f'/>
<id>df29ebfe02aa0639278527b0fa2d90074263af0f</id>
<content type='text'>
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 &lt;sbrivio@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;sbrivio@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>test/perf: Switch performance test duration to 10 seconds instead of 30</title>
<updated>2022-09-22T14:53:55+00:00</updated>
<author>
<name>Stefano Brivio</name>
<email>sbrivio@redhat.com</email>
</author>
<published>2022-09-18T13:39:59+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=a39398e840cfc7b8608cab10e30efeab3188db2e'/>
<id>a39398e840cfc7b8608cab10e30efeab3188db2e</id>
<content type='text'>
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 &lt;sbrivio@redhat.com&gt;
Reviewed-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;sbrivio@redhat.com&gt;
Reviewed-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>test/perf: Check for /sbin/sysctl with which(1), not simply sysctl</title>
<updated>2022-09-22T14:53:35+00:00</updated>
<author>
<name>Stefano Brivio</name>
<email>sbrivio@redhat.com</email>
</author>
<published>2022-09-16T23:17:04+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=ae51d2dac108e8daa475e4d6c1a6a5ebbb3fa759'/>
<id>ae51d2dac108e8daa475e4d6c1a6a5ebbb3fa759</id>
<content type='text'>
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 &lt;sbrivio@redhat.com&gt;
Reviewed-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;sbrivio@redhat.com&gt;
Reviewed-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>test: Parameterize run time for throughput performance tests</title>
<updated>2022-09-07T09:01:22+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-09-02T02:04:33+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=29247d0db6953d7a3d45c4da763b487ef695ac1e'/>
<id>29247d0db6953d7a3d45c4da763b487ef695ac1e</id>
<content type='text'>
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 &lt;david@gibson.dropbear.id.au&gt;
[sbrivio: Reflect new parameter in comment to test_iperf3()]
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;david@gibson.dropbear.id.au&gt;
[sbrivio: Reflect new parameter in comment to test_iperf3()]
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>test: Combine iperf3c and iperf3s into a single DSL command</title>
<updated>2022-09-07T09:01:22+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-09-02T02:04:32+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=5c13b511d9e97ae24cfa7bb87a1e23648c8d8249'/>
<id>5c13b511d9e97ae24cfa7bb87a1e23648c8d8249</id>
<content type='text'>
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 &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tests: Explicitly list test files in test/run, remove "onlyfor" support</title>
<updated>2022-07-13T23:32:42+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-07-06T07:29:06+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=a832a44e67e77dd1a9ec57e9c054feddb0355cfc'/>
<id>a832a44e67e77dd1a9ec57e9c054feddb0355cfc</id>
<content type='text'>
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 &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>test: Embed script for dhclient(8) in mbuto(1) profile</title>
<updated>2022-07-13T23:31:28+00:00</updated>
<author>
<name>Stefano Brivio</name>
<email>sbrivio@redhat.com</email>
</author>
<published>2022-07-07T14:39:09+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=4d777144fd214bf67153f1dfa8e1e7b52b44ae35'/>
<id>4d777144fd214bf67153f1dfa8e1e7b52b44ae35</id>
<content type='text'>
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 &lt;david@gibson.dropbear.id.au&gt;
Suggested-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;

note that we need to bring up the interface before starting dhclient
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;david@gibson.dropbear.id.au&gt;
Suggested-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;

note that we need to bring up the interface before starting dhclient
</pre>
</div>
</content>
</entry>
<entry>
<title>Tweak dhclient arguments for readability</title>
<updated>2022-06-15T07:38:10+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-06-10T02:32:43+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=ca0c33ae5b8a68806dd1c766e2f58ce24867f334'/>
<id>ca0c33ae5b8a68806dd1c766e2f58ce24867f334</id>
<content type='text'>
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 &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
</feed>
