public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Christian Marangi <ansuelsmth@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Atin Bainada <hi@atinb.me>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [net-next PATCH RFC] net: dsa: qca8k: make learning configurable and keep off if standalone
Date: Mon, 26 Jun 2023 20:30:56 +0300	[thread overview]
Message-ID: <20230626173056.zq77nilzrr5djns5@skbuf> (raw)
In-Reply-To: <6499c31c.df0a0220.e2acb.5549@mx.google.com>

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.

  reply	other threads:[~2023-06-26 17:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-23 11:40 [net-next PATCH RFC] net: dsa: qca8k: make learning configurable and keep off if standalone Christian Marangi
2023-06-25 11:58 ` Vladimir Oltean
2023-06-26 16:41   ` Christian Marangi
2023-06-26 17:30     ` Vladimir Oltean [this message]
2023-06-26 17:59       ` Christian Marangi
2023-06-27  9:49         ` Vladimir Oltean
2023-06-28  0:49           ` Christian Marangi
2023-06-28  0:53             ` Christian Marangi
2023-06-29 12:49               ` Vladimir Oltean
2023-06-29 12:39             ` Vladimir Oltean
2023-07-01 18:25               ` Christian Marangi
2023-07-04 23:34                 ` Vladimir Oltean

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230626173056.zq77nilzrr5djns5@skbuf \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=ansuelsmth@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=hi@atinb.me \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox