[net] selftests: net: add missing config for big tcp tests

The big_tcp test-case requires a few kernel knobs currently
not specified in the net selftests config, causing the
following failure:

  # selftests: net: big_tcp.sh
  # Error: Failed to load TC action module.
  # We have an error talking to the kernel
...
  # Testing for BIG TCP:
  # CLI GSO | GW GRO | GW GSO | SER GRO
  # ./big_tcp.sh: line 107: test: !=: unary operator expected
...
  # on        on       on       on      : [FAIL_on_link1]

Add the missing configs

Fixes: 6bb382bcf742 ("selftests: add a selftest for big tcp")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
 tools/testing/selftests/net/config | 5 +++++
 1 file changed, 5 insertions(+)

Paolo Abeni <pabeni@redhat.com> writes:

> The big_tcp test-case requires a few kernel knobs currently
> not specified in the net selftests config, causing the
> following failure:
>
>   # selftests: net: big_tcp.sh
>   # Error: Failed to load TC action module.
>   # We have an error talking to the kernel
> ...
>   # Testing for BIG TCP:
>   # CLI GSO | GW GRO | GW GSO | SER GRO
>   # ./big_tcp.sh: line 107: test: !=: unary operator expected
> ...
>   # on        on       on       on      : [FAIL_on_link1]
>
> Add the missing configs
>
> Fixes: 6bb382bcf742 ("selftests: add a selftest for big tcp")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---

Thanks for the fix.

Maybe we should also add the config for NET_ACT_CT since we will
invoke it on setup.  I guess there's some dependency that must be
pulling it in for us already so we don't explicitly call for it, but we
do require it in setup() if I understand correctly.  I don't think it
should hold up this patch though.

Acked-by: Aaron Conole <aconole@redhat.com>

On Fri, 2024-01-26 at 11:18 -0500, Aaron Conole wrote:
> Paolo Abeni <pabeni@redhat.com> writes:
> 
> > The big_tcp test-case requires a few kernel knobs currently
> > not specified in the net selftests config, causing the
> > following failure:
> > 
> >   # selftests: net: big_tcp.sh
> >   # Error: Failed to load TC action module.
> >   # We have an error talking to the kernel
> > ...
> >   # Testing for BIG TCP:
> >   # CLI GSO | GW GRO | GW GSO | SER GRO
> >   # ./big_tcp.sh: line 107: test: !=: unary operator expected
> > ...
> >   # on        on       on       on      : [FAIL_on_link1]
> > 
> > Add the missing configs
> > 
> > Fixes: 6bb382bcf742 ("selftests: add a selftest for big tcp")
> > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > ---
> 
> Thanks for the fix.
> 
> Maybe we should also add the config for NET_ACT_CT since we will
> invoke it on setup.  I guess there's some dependency that must be
> pulling it in for us already so we don't explicitly call for it, but we
> do require it in setup() if I understand correctly.  

This patch already adds NET_ACT_CT=m:

> @@ -71,6 +74,7 @@ CONFIG_NET_CLS_FLOWER=m
>  CONFIG_NET_CLS_BPF=m
>  CONFIG_NET_ACT_TUNNEL_KEY=m
>  CONFIG_NET_ACT_MIRRED=m
> +CONFIG_NET_ACT_CT=m
>  CONFIG_BAREUDP=m
>  CONFIG_IPV6_IOAM6_LWTUNNEL=y
>  CONFIG_CRYPTO_SM4_GENERIC=y

Cheers,

Paolo

On Mon, 29 Jan 2024 17:31:33 +0100 Paolo Abeni wrote:
> Uhm... while the self-test doesn't emit anymore the message related to
> the missing modules, it still fails in the CI env and I can't reproduce
> the failures in my local env (the same for the gro.sh script).
> 
> If I understand correctly, the tests run under double virtualization (a
> VM on top AWS?), is that correct? I guess the extra slowdown/overhead
> will need more care.

Yes, it's VM inside a VM without nested virtualization support.
A weird setup, granted, but when we move to bare metal I'd like
to enable KASAN, which will probably cause a similar slowdown..

You could possibly get a similar slowdown by disabling HW virt /
KVM?

FWIW far the 4 types of issues we've seen were:
 - config missing
 - OS doesn't ifup by default
 - OS tools are old / buggy
 - VM-in-VM is just too slow.

There's a bunch of failures in forwarding which look like perf issues.
I wonder if we should introduce something in the settings file to let
tests know that they are running in very slow env?