Messages in this thread | | | Date | Mon, 26 Jun 2023 19:59:41 +0200 | From | Christian Marangi <> | Subject | Re: [net-next PATCH RFC] net: dsa: qca8k: make learning configurable and keep off if standalone |
| |
On Mon, Jun 26, 2023 at 08:30:56PM +0300, Vladimir Oltean wrote: > On Mon, Jun 26, 2023 at 06:41:50PM +0200, Christian Marangi wrote: > > > Once that basic precondition passes, you should be able to start looking > > > at tools/testing/selftests/drivers/net/dsa/ and run those one by one. > > > An interesting one would be local_termination.sh, which monitors the way > > > in which frames reach the CPU. Though be aware that some sub-tests from > > > that suite will fail on misconfigurations that are non-fatal (and don't > > > impact functionality), just sub-optimal (affecting performance). Like > > > sending unknown packets to the CPU when the port is non-promiscuous and > > > software would drop those packets anyway. > > > > > > > Lots of difficult to run the selftests on a light fw but step at times > > I'm managing to make use of them (could be helpfull to add some comments > > in the .config saying that the testing port needs to be declared in the > > struct) (and maybe some additional checks on the kind of device type are > > required for the test to actually work (vrf, dummy, macvlan...) > > Yeah, that doesn't sound like a bad idea at all. AFAIK, > tools/testing/selftests/net/forwarding/lib.sh doesn't check > "zcat /proc/config.gz" at all. Maybe it would be nice if it did, and to > guard that behavior based on some REQUIRE_* variables that are true by > default (but can be set to false by scripts). >
Some thing can even be checked by simply creating an interface and see if the thing gives error. I feel this is a better approach than checking config and kflags since from what I can see the idea of these scripts is to be system agnostic and sometimes it's handy to ""compile"" or package these scripts on a different system than the target one (this is true for every shell script and target specific stuff that needs to be compiled is not the case)
> > Anyway a run of local_termination.sh produce the following output. > > # selftests: drivers/net/dsa: local_termination.sh > > # TEST: lan1: Unicast IPv4 to primary MAC address [FAIL] > > # reception failed > > Hmm, so ping works but this doesn't? That's strange, because send_uc_ipv4() > also pings. Have you run with bash -x to see why it fails? >
I just run with bash -x and I also mod the script to not delete the tcpdump. Limiting the script to only this test the dump is just 2 ICMPv6 packet and no output from tcpdump aside from
tcpdump: listening on lan1, link-type EN10MB (Ethernet), snapshot length 65535 bytes 3 packets captured 5 packets received by filter 0 packets dropped by kernel
I feel like this is important so I think I should focus on understanding why this doesn't work? Any clue?
> > # TEST: lan1: Unicast IPv4 to macvlan MAC address [FAIL] > > # reception failed > > # TEST: lan1: Unicast IPv4 to unknown MAC address [ OK ] > > So the only reason why this test passes is because in this case, the > unicast drops are okay? > > > # TEST: lan1: Unicast IPv4 to unknown MAC address, promisc [FAIL] > > # reception failed > > # TEST: lan1: Unicast IPv4 to unknown MAC address, allmulti [ OK ] > > Similar here. Packet should have been dropped; the test detects a drop => okay. > Passes for the wrong reason, most likely, because this driver doesn't react > on IFF_PROMISC or IFF_ALLMULTI. > > > # TEST: lan1: Multicast IPv4 to joined group [ OK ] > > # TEST: lan1: Multicast IPv4 to unknown group [FAIL] > > # reception succeeded, but should have failed > > "reception succeeded, but should have failed" is the okay kind of failure. > "reception failed" is what's bothering. > > > # TEST: lan1: Multicast IPv4 to unknown group, promisc [FAIL] > > # reception failed > > # TEST: lan1: Multicast IPv4 to unknown group, allmulti [ OK ] > > # TEST: lan1: Multicast IPv6 to joined group [ OK ] > > # TEST: lan1: Multicast IPv6 to unknown group [FAIL] > > # reception succeeded, but should have failed > > # TEST: lan1: Multicast IPv6 to unknown group, promisc [FAIL] > > # reception failed > > This I cannot explain. For the test right above, "Multicast IPv6 to unknown group", > it said that reception succeeded. This is sending the same packet, only > the IFF_PROMISC flag of the device changes (this is also propagated to > the DSA master). I've no idea why it fails. Again, bash -x will say more. > > > # TEST: lan1: Multicast IPv6 to unknown group, allmulti [ OK ] > > # TEST: br0: Unicast IPv4 to primary MAC address [FAIL] > > # reception failed > > # TEST: br0: Unicast IPv4 to macvlan MAC address [FAIL] > > # reception failed > > # TEST: br0: Unicast IPv4 to unknown MAC address [ OK ] > > # TEST: br0: Unicast IPv4 to unknown MAC address, promisc [FAIL] > > # reception failed > > # TEST: br0: Unicast IPv4 to unknown MAC address, allmulti [ OK ] > > # TEST: br0: Multicast IPv4 to joined group [ OK ] > > # TEST: br0: Multicast IPv4 to unknown group [FAIL] > > # reception succeeded, but should have failed > > # TEST: br0: Multicast IPv4 to unknown group, promisc [FAIL] > > # reception failed > > # TEST: br0: Multicast IPv4 to unknown group, allmulti [ OK ] > > # TEST: br0: Multicast IPv6 to joined group [ OK ] > > # TEST: br0: Multicast IPv6 to unknown group [FAIL] > > # reception succeeded, but should have failed > > # TEST: br0: Multicast IPv6 to unknown group, promisc [FAIL] > > # reception failed > > # TEST: br0: Multicast IPv6 to unknown group, allmulti [ OK ] > > > > Things doesn't look good to me or I am wrong? > > Nope, doesn't look good at all. Looks like an incomplete setup.
-- Ansuel
| |