On 05/08/2020 09:44, Willem de Bruijn wrote: > On Wed, Aug 5, 2020 at 10:22 AM Colin Ian King <colin.king@xxxxxxxxxxxxx> wrote: >> >> On 05/08/2020 09:06, Willem de Bruijn wrote: >>> On Wed, Aug 5, 2020 at 2:54 AM Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote: >>>> >>>> >>>> >>>> On 8/4/20 5:30 AM, Colin King wrote: >>>>> From: Colin Ian King <colin.king@xxxxxxxxxxxxx> >>>>> >>>>> 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@xxxxxxxxxxxxx> >>>>> --- >>>>> 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 :-) > > Certainly not a bad fix! Thanks for addressing the issue. Alternative > approach at > > http://patchwork.ozlabs.org/project/netdev/patch/20200805084045.1549492-1-willemdebruijn.kernel@xxxxxxxxx/ > Thanks, you solution is good for my testing requirements Acked-by: Colin Ian King <colin.king@xxxxxxxxxxxxx>
