| Message ID | 20221101184809.50013-1-athierry@redhat.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | cdb525ca92b196f8916102b62431aa0d9a644ff2 |
| Headers | show |
| Series | selftests/net: give more time to udpgro bg processes to complete startup | expand |
On Tue, 1 Nov 2022 14:48:08 -0400 Adrien Thierry wrote: > In some conditions, background processes in udpgro don't have enough > time to set up the sockets. When foreground processes start, this > results in the test failing with "./udpgso_bench_tx: sendmsg: Connection > refused". For instance, this happens from time to time on a Qualcomm > SA8540P SoC running CentOS Stream 9. > > To fix this, increase the time given to background processes to > complete the startup before foreground processes start. > > Signed-off-by: Adrien Thierry <athierry@redhat.com> > --- > This is a continuation of the hack that's present in those tests. Other > ideas are welcome to fix this in a more permanent way. Perhaps we can add an option to the Rx side to daemonize itself after setting up the socket, that way the bash script will be locked until Rx is ready?
On Thu, 2022-11-03 at 20:46 -0700, Jakub Kicinski wrote: > On Tue, 1 Nov 2022 14:48:08 -0400 Adrien Thierry wrote: > > In some conditions, background processes in udpgro don't have enough > > time to set up the sockets. When foreground processes start, this > > results in the test failing with "./udpgso_bench_tx: sendmsg: Connection > > refused". For instance, this happens from time to time on a Qualcomm > > SA8540P SoC running CentOS Stream 9. > > > > To fix this, increase the time given to background processes to > > complete the startup before foreground processes start. > > > > Signed-off-by: Adrien Thierry <athierry@redhat.com> > > --- > > This is a continuation of the hack that's present in those tests. Other > > ideas are welcome to fix this in a more permanent way. > > Perhaps we can add an option to the Rx side to daemonize itself after > setting up the socket, that way the bash script will be locked until > Rx is ready? Then it will be less straigh-forward for the running shell waiting for all the running processes. Another option would be replacing the sleep with a loop waiting for the rx UDP socket to appear in the procfs or diag interface, alike what mptcp self-tests (random example;) are doing: https://elixir.bootlin.com/linux/v6.1-rc3/source/tools/testing/selftests/net/mptcp/mptcp_join.sh#L424 Cheers, Paolo
Hello: This patch was applied to netdev/net.git (master) by David S. Miller <davem@davemloft.net>: On Tue, 1 Nov 2022 14:48:08 -0400 you wrote: > In some conditions, background processes in udpgro don't have enough > time to set up the sockets. When foreground processes start, this > results in the test failing with "./udpgso_bench_tx: sendmsg: Connection > refused". For instance, this happens from time to time on a Qualcomm > SA8540P SoC running CentOS Stream 9. > > To fix this, increase the time given to background processes to > complete the startup before foreground processes start. > > [...] Here is the summary with links: - selftests/net: give more time to udpgro bg processes to complete startup https://git.kernel.org/netdev/net/c/cdb525ca92b1 You are awesome, thank you!
On Fri, 04 Nov 2022 09:54:10 +0100 Paolo Abeni wrote: > Then it will be less straigh-forward for the running shell waiting for > all the running processes. The usual solution for that is to write the pid of the daemonized process to a file, no? > Another option would be replacing the sleep with a loop waiting for > the rx UDP socket to appear in the procfs or diag interface, alike what > mptcp self-tests (random example;) are doing:
diff --git a/tools/testing/selftests/net/udpgro.sh b/tools/testing/selftests/net/udpgro.sh index ebbd0b282432..6a443ca3cd3a 100755 --- a/tools/testing/selftests/net/udpgro.sh +++ b/tools/testing/selftests/net/udpgro.sh @@ -50,7 +50,7 @@ run_one() { echo "failed" & # Hack: let bg programs complete the startup - sleep 0.1 + sleep 0.2 ./udpgso_bench_tx ${tx_args} ret=$? wait $(jobs -p) @@ -117,7 +117,7 @@ run_one_2sock() { echo "failed" & # Hack: let bg programs complete the startup - sleep 0.1 + sleep 0.2 ./udpgso_bench_tx ${tx_args} -p 12345 sleep 0.1 # first UDP GSO socket should be closed at this point diff --git a/tools/testing/selftests/net/udpgro_bench.sh b/tools/testing/selftests/net/udpgro_bench.sh index fad2d1a71cac..8a1109a545db 100755 --- a/tools/testing/selftests/net/udpgro_bench.sh +++ b/tools/testing/selftests/net/udpgro_bench.sh @@ -39,7 +39,7 @@ run_one() { ip netns exec "${PEER_NS}" ./udpgso_bench_rx -t ${rx_args} -r & # Hack: let bg programs complete the startup - sleep 0.1 + sleep 0.2 ./udpgso_bench_tx ${tx_args} } diff --git a/tools/testing/selftests/net/udpgro_frglist.sh b/tools/testing/selftests/net/udpgro_frglist.sh index 832c738cc3c2..7fe85ba51075 100755 --- a/tools/testing/selftests/net/udpgro_frglist.sh +++ b/tools/testing/selftests/net/udpgro_frglist.sh @@ -44,7 +44,7 @@ run_one() { ip netns exec "${PEER_NS}" ./udpgso_bench_rx ${rx_args} -r & # Hack: let bg programs complete the startup - sleep 0.1 + sleep 0.2 ./udpgso_bench_tx ${tx_args} }
In some conditions, background processes in udpgro don't have enough time to set up the sockets. When foreground processes start, this results in the test failing with "./udpgso_bench_tx: sendmsg: Connection refused". For instance, this happens from time to time on a Qualcomm SA8540P SoC running CentOS Stream 9. To fix this, increase the time given to background processes to complete the startup before foreground processes start. Signed-off-by: Adrien Thierry <athierry@redhat.com> --- This is a continuation of the hack that's present in those tests. Other ideas are welcome to fix this in a more permanent way. tools/testing/selftests/net/udpgro.sh | 4 ++-- tools/testing/selftests/net/udpgro_bench.sh | 2 +- tools/testing/selftests/net/udpgro_frglist.sh | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-)