From: Christian Marangi <ansuelsmth@gmail.com>
To: Vladimir Oltean <olteanv@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: Wed, 28 Jun 2023 02:53:35 +0200 [thread overview]
Message-ID: <649c39fe.050a0220.633cf.c865@mx.google.com> (raw)
In-Reply-To: <649c3931.df0a0220.136ab.2fb7@mx.google.com>
On Wed, Jun 28, 2023 at 02:49:53AM +0200, Christian Marangi wrote:
> On Tue, Jun 27, 2023 at 12:49:16PM +0300, Vladimir Oltean wrote:
> > On Mon, Jun 26, 2023 at 07:59:41PM +0200, Christian Marangi wrote:
> > > > 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?
> >
> > No clue. I'd put a "bash" instruction in send_uc_ipv4(), which would act
> > as a sort of break point for the script (opens an interactive sub-shell),
> > then run it again with bash -x, manually repeat the command that failed,
> > investigate why it failed and hit Ctrl-d when I'm done.
>
> Hi, I wasted a day to only notice that the problem was in busybox not
> supporting 0.x value and that is what selfttest script use. Another
> thing to check. Also the confusing part of this is that we don't check
> if ping_do return error and the test just fails (while in reality the
> ping command was never executed)
>
Also sorry for the double email... I forgot to add that it seems I need
to add a sleep 1 right after
mc_route_prepare $h1
mc_route_prepare $rcv_if_name
in local_termination.sh. Think the switch needs some time to enable all
the port. Without the sleep 1 the first test just fails.
> Anyway I'm fixing all kind of bugs and I even found an even hw
> limitation with the FDB table with mgmt packet...
>
> Also I implemented fdb_insolation following the implementation done on
> felix with reserving VID at the end...
> About this I wonder if it might be a good idea to expose some generic
> API from DSA?
>
> qca8k require a reserved VID for VLAN unaware port and with
> fdb_isolation even more VID are reserved. DSA have no idea about this so
> I wonder if there is a chance of VID clash? I feel like we need
> something to declare a range of reserved VID so that they gets rejected
> when applied. (about this I think I should return -EINVAL if fdb/mbd
> insert are asked with a reserved VID)
>
> Anyway by fixing that interval problem (enabling support in busybox as
> it's disabled by default in a OpenWRT system)
> This is the new output of the local_termination.sh
>
> TAP version 13
> 1..1
> # selftests: drivers/net/dsa: local_termination.sh
> # TEST: lan1: Unicast IPv4 to primary MAC address [ OK ]
> # TEST: lan1: Unicast IPv4 to macvlan MAC address [ OK ]
> # TEST: lan1: Unicast IPv4 to unknown MAC address [FAIL]
> # reception succeeded, but should have failed
> # TEST: lan1: Unicast IPv4 to unknown MAC address, promisc [ OK ]
> # TEST: lan1: Unicast IPv4 to unknown MAC address, allmulti [FAIL]
> # reception succeeded, but should have failed
> # TEST: lan1: Multicast IPv4 to joined group [ OK ]
> # TEST: lan1: Multicast IPv4 to unknown group [FAIL]
> # reception succeeded, but should have failed
> # TEST: lan1: Multicast IPv4 to unknown group, promisc [ OK ]
> # 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 [ OK ]
> # TEST: lan1: Multicast IPv6 to unknown group, allmulti [ OK ]
> # TEST: br0: Unicast IPv4 to primary MAC address [ OK ]
> # TEST: br0: Unicast IPv4 to macvlan MAC address [ OK ]
> # TEST: br0: Unicast IPv4 to unknown MAC address [FAIL]
> # reception succeeded, but should have failed
> # TEST: br0: Unicast IPv4 to unknown MAC address, promisc [ OK ]
> # TEST: br0: Unicast IPv4 to unknown MAC address, allmulti [FAIL]
> # reception succeeded, but should have failed
> # 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 [ OK ]
> # 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 [ OK ]
> # TEST: br0: Multicast IPv6 to unknown group, allmulti [ OK ]
> not ok 1 selftests: drivers/net/dsa: local_termination.sh # exit=1
>
> Seems good aside from the reception secceeded that I think the kernel
> just drops right?
>
> The switch have a way to control FLOOD per port but maybe the correct
> feature to use is the VLAN leaky? Where the setting can be set by both
> FDB/MBD and per port.
>
> Sorry if I described some fix and implementation without proposing the
> patch but I would like some comments on what the tool returned.
>
> --
> Ansuel
--
Ansuel
next prev parent reply other threads:[~2023-06-28 13:47 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
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 [this message]
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=649c39fe.050a0220.633cf.c865@mx.google.com \
--to=ansuelsmth@gmail.com \
--cc=andrew@lunn.ch \
--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=olteanv@gmail.com \
--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;
as well as URLs for NNTP newsgroup(s).