On 05/08/2020 09:06, Willem de Bruijn wrote:
On Wed, Aug 5, 2020 at 2:54 AM Eric Dumazet eric.dumazet@gmail.com wrote:
On 8/4/20 5:30 AM, Colin King wrote:
From: Colin Ian King colin.king@canonical.com
The current test will exit with a failure if it cannot set affinity on specific CPUs which is problematic when running this on single CPU systems. Add a check for the number of CPUs and skip the test if the CPU requirement is not met.
Signed-off-by: Colin Ian King colin.king@canonical.com
tools/testing/selftests/net/msg_zerocopy.sh | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/tools/testing/selftests/net/msg_zerocopy.sh b/tools/testing/selftests/net/msg_zerocopy.sh index 825ffec85cea..97bc527e1297 100755 --- a/tools/testing/selftests/net/msg_zerocopy.sh +++ b/tools/testing/selftests/net/msg_zerocopy.sh @@ -21,6 +21,11 @@ readonly DADDR6='fd::2'
readonly path_sysctl_mem="net.core.optmem_max"
+if [[ $(nproc) -lt 4 ]]; then
echo "SKIP: test requires at least 4 CPUs"exit 4+fi
# No arguments: automated test if [[ "$#" -eq "0" ]]; then $0 4 tcp -t 1
Test explicitly uses CPU 2 and 3, right ?
nproc could be 500, yet cpu 2 or 3 could be offline
# cat /sys/devices/system/cpu/cpu3/online 0 # echo $(nproc) 71
The cpu affinity is only set to bring some stability across runs.
The test does not actually verify that a run with zerocopy is some factor faster than without, as that factor is hard to choose across all platforms. As a result the automated run mainly gives code coverage.
It's preferable to always run. And on sched_setaffinity failure log a message about possible jitter and continue. I can send that patch, if the approach sounds good.
That's sounds preferable to my bad fix for sure :-)
Colin