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/
