Messages in this thread | | | Date | Fri, 21 Jul 2023 22:41:30 +0200 | Subject | Re: [PROBLEM] selftests: net/forwarding/*.sh: 'Command line is not complete. Try option "help"' | From | Mirsad Todorovac <> |
| |
On 7/19/23 14:59, Ido Schimmel wrote: > On Tue, Jul 18, 2023 at 08:39:33PM +0200, Mirsad Todorovac wrote: >> There is also a gotcha here: you do not delete all veths: >> >> root@defiant:# ip link show >> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 >> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >> 2: enp16s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 >> link/ether 9c:6b:00:01:fb:80 brd ff:ff:ff:ff:ff:ff >> root@defiant:# ./bridge_igmp.sh > > [...] > >> root@defiant:# ip link show >> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 >> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >> 2: enp16s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 >> link/ether 9c:6b:00:01:fb:80 brd ff:ff:ff:ff:ff:ff >> 3: veth1@veth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000 >> link/ether b6:46:e6:4c:e4:00 brd ff:ff:ff:ff:ff:ff >> 4: veth0@veth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000 >> link/ether 2e:ff:7f:8a:6b:d4 brd ff:ff:ff:ff:ff:ff >> 5: veth3@veth2: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000 >> link/ether ba:33:37:81:dc:5b brd ff:ff:ff:ff:ff:ff >> 6: veth2@veth3: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000 >> link/ether f2:fd:0a:9b:94:17 brd ff:ff:ff:ff:ff:ff >> root@defiant:# > > These tests can be run with veth pairs or with loop backed physical > ports. We can't delete the latter and I don't see a clean way to delete > the veth pairs. > > The following patch [1] changes the default to not create interfaces so > that by default these tests will be skipped [2]. Those who care about > running the tests can create a forwarding.config file (using > forwarding.config.sample as an example) and either create the veth pairs > themselves or opt-in for the interfaces to be created automatically > (setting NETIF_CREATE=yes), but not deleted. > > [1] > diff --git a/tools/testing/selftests/net/forwarding/forwarding.config.sample b/tools/testing/selftests/net/forwarding/forwarding.config.sample > index 4a546509de90..b72f08dfd491 100644 > --- a/tools/testing/selftests/net/forwarding/forwarding.config.sample > +++ b/tools/testing/selftests/net/forwarding/forwarding.config.sample > @@ -36,8 +36,9 @@ PAUSE_ON_FAIL=no > PAUSE_ON_CLEANUP=no > # Type of network interface to create > NETIF_TYPE=veth > -# Whether to create virtual interfaces (veth) or not > -NETIF_CREATE=yes > +# Whether to create virtual interfaces (veth) or not. Created interfaces are > +# not automatically deleted > +NETIF_CREATE=no > # Timeout (in seconds) before ping exits regardless of how many packets have > # been sent or received > PING_TIMEOUT=5 > diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh > index 9ddb68dd6a08..1b1bc634c63e 100755 > --- a/tools/testing/selftests/net/forwarding/lib.sh > +++ b/tools/testing/selftests/net/forwarding/lib.sh > @@ -17,7 +17,7 @@ WAIT_TIME=${WAIT_TIME:=5} > PAUSE_ON_FAIL=${PAUSE_ON_FAIL:=no} > PAUSE_ON_CLEANUP=${PAUSE_ON_CLEANUP:=no} > NETIF_TYPE=${NETIF_TYPE:=veth} > -NETIF_CREATE=${NETIF_CREATE:=yes} > +NETIF_CREATE=${NETIF_CREATE:=no} > MCD=${MCD:=smcrouted} > MC_CLI=${MC_CLI:=smcroutectl} > PING_COUNT=${PING_COUNT:=10} > > [2] > # ./bridge_igmp.sh > SKIP: could not find all required interfaces
Hi, Ido,
Please would you consider making a formal patch, so the vanilla 'make kselftest' run would have some sensible defaults?
I am really interested in the network stack working right, though I really do not have much opportunities testing like high speed links and bonded eth adapters :-(
Maybe that'll come :-/
Kind regards, Mirsad
| |