[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230626173056.zq77nilzrr5djns5@skbuf>
Date: Mon, 26 Jun 2023 20:30:56 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Atin Bainada <hi@...nb.me>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [net-next PATCH RFC] net: dsa: qca8k: make learning configurable
and keep off if standalone
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).
> 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?
> # 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.
Powered by blists - more mailing lists