From: Tobias Waldekranz <tobias@waldekranz.com>
To: Etienne Champetier <champetier.etienne@gmail.com>,
Vladimir Oltean <vladimir.oltean@nxp.com>,
Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: mv88e6xxx / MV88E6176 + VLAN-aware unusable in 5.15.98 (ok in 5.10.168) (resend)
Date: Sun, 12 Mar 2023 13:11:43 +0100 [thread overview]
Message-ID: <87edpudv9c.fsf@waldekranz.com> (raw)
In-Reply-To: <cd306c78-14a6-bebb-e174-2917734b4799@gmail.com>
On sön, mar 12, 2023 at 00:41, Etienne Champetier <champetier.etienne@gmail.com> wrote:
> (properly formatted this time)
>
> Hello Vladimir, Tobias,
>
> Sending this email to both of you as reverting some of your patches 'fix' the issues I'm seeing.
> I'm slowly investigating a regression in OpenWrt going from 22.03 (5.10.168 + some backports)
> to current master (5.15.98 + some backports). Using my Turris Omnia (MV88E6176) with the following network config:
>
> # bridge vlan
> port vlan-id
> lan0 6 PVID Egress Untagged
> lan1 5 PVID Egress Untagged
> lan2 4 PVID Egress Untagged
> lan3 3 PVID Egress Untagged
> lan4 2 PVID Egress Untagged
> br-lan 2
> 3
> 4
> 5
> 6
> wlan1 3 PVID Egress Untagged
> wlan1-1 5 PVID Egress Untagged
> wlan1-2 6 PVID Egress Untagged
> wlan0 2 PVID Egress Untagged
>
> I get tagged frame with VID 3 on lan4 (at least some multicast & broadcast), but lan4 is not a member of VLAN 3
Are these packets being sent to the CPU with a FORWARD tag or TO_CPU? If
it is the latter, what is the CPU_CODE set to? Better yet, could you
post some output from `tcpdump -Q in -evnli <YOUR-DSA-INTERFACE>`?
> Also unicast frames from wifi to lan4 exit tagged with VID 2, broadcast frames are fine (verifed with scapy)
If you're capturing on the lan4 interface, this is to be expected.
When forwarding offloading is enabled. In order for the tag driver to
generate the correct DSA tag, we need to know to which VLAN the packet
belongs (there could be more than one VLAN configured to egress
untagged). Since a FORWARD tag is (should be) generated, the switch will
handle the stripping of the VLAN tag for untagged members.
If you tcpdump at the DSA interface, are the packet sent to the switch
with a FORWARD tag or FROM_CPU?
> Reverting
> 5bded8259ee3 "net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports" from Vladimir
> and
> b80dc51b72e2 "net: dsa: mv88e6xxx: Only allow LAG offload on supported hardware"
> 57e661aae6a8 "net: dsa: mv88e6xxx: Link aggregation support"
> from Tobias allow me to get back to 5.10 behavior / working system.
>
> On the OpenWrt side, 5.15 is the latest supported kernel, so I was not able to try more recent for now.
>
> I'm happy to try to backport any patches that can help fix or narrow down the issue, or provide more infos / tests results.
>
> These issues affect other devices using mv88e6xxx: https://github.com/openwrt/openwrt/issues/11877
> In the Github issue the reporter note that first packet is not tagged and the following are.
>
> Here a diff of "mv88e6xxx_dump --vtu --ports --global1 --global2" between 5.10 and 5.15 (without revert)
>
> @@ -9,18 +9,18 @@
> 05 Port control 1 0000 0000 0000 0000 0000 0000 0000
> 06 Port base VLAN map 007e 007d 007b 0077 006f 005f 003f
> 07 Def VLAN ID & Prio 0006 0005 0004 0003 0002 0000 0000
> -08 Port control 2 0c80 0c80 0c80 0c80 0c80 1080 2080
> +08 Port control 2 0c80 0c80 0c80 0c80 0c80 1080 1080
> 09 Egress rate control 0001 0001 0001 0001 0001 0001 0001
> 0a Egress rate control 2 0000 0000 0000 0000 0000 0000 0000
> -0b Port association vec 1001 1002 1004 1008 1010 1000 1000
> +0b Port association vec 1001 1002 1004 1008 1010 1020 1040
> 0c Port ATU control 0000 0000 0000 0000 0000 0000 0000
> 0d Override 0000 0000 0000 0000 0000 0000 0000
> 0e Policy control 0000 0000 0000 0000 0000 0000 0000
> 0f Port ether type 9100 9100 9100 9100 9100 dada dada
> 10 In discard low 0000 0000 0000 0000 0000 0000 0000
> 11 In discard high 0000 0000 0000 0000 0000 0000 0000
> -12 In filtered 0000 0000 0000 0000 0000 0000 0000
> -13 RX frame count 0000 0000 0000 008c 0000 021a 0000
> +12 In filtered 0000 0000 0000 0003 0000 0000 0000
> +13 RX frame count 0000 0000 0000 008e 0000 04dd 0000
> 14 Reserved 0000 0000 0000 0000 0000 0000 0000
> 15 Reserved 0000 0000 0000 0000 0000 0000 0000
> 16 LED control 0000 0000 0000 0000 0000 0000 0000
> @@ -39,22 +39,23 @@
> T - a member, egress tagged
> X - not a member, Ingress frames with VID discarded
> P VID 0123456 FID SID QPrio FPrio VidPolicy
> -0 1 XXXXXVV 1 0 - - 0
> -0 2 XXXXUVV 6 0 - - 0
> -0 3 XXXUXVV 5 0 - - 0
> -0 4 XXUXXVV 4 0 - - 0
> -0 5 XUXXXVV 3 0 - - 0
> -0 6 UXXXXVV 2 0 - - 0
> +0 1 XXXXXVV 2 0 - - 0
> +0 2 XXXXUVV 7 0 - - 0
> +0 3 XXXUXVV 6 0 - - 0
> +0 4 XXUXXVV 5 0 - - 0
> +0 5 XUXXXVV 4 0 - - 0
> +0 6 UXXXXVV 3 0 - - 0
> +0 4095 UUUUUVV 1 0 - - 0
> Global1:
> 00 Global status c814
> -01 ATU FID 0006
> -02 VTU FID 0002
> +01 ATU FID 0007
> +02 VTU FID 0001
> 03 VTU SID 0000
> 04 Global control 40a8
> -05 VTU operations 4000
> -06 VTU VID 0fff
> -07 VTU/STU Data 0-3 3331
> -08 VTU/STU Data 4-6 0303
> +05 VTU operations 4043
> +06 VTU VID 1fff
> +07 VTU/STU Data 0-3 1111
> +08 VTU/STU Data 4-6 0111
> 09 Reserved 0000
> 0a ATU control 0149
> 0b ATU operations 4000
> @@ -90,10 +91,10 @@
> 08 Trunk mapping 7800
> 09 Ingress rate command 1600
> 0a Ingress rate data 0000
> -0b Cross chip port VLAN addr 31ff
> -0c Cross chip port VLAN data 0000
> -0d Switch MAC/WoL/WoF 05c5
> -0e ATU Stats 000f
> +0b Cross chip port VLAN addr 3010
> +0c Cross chip port VLAN data 007f
> +0d Switch MAC/WoL/WoF 05fe
> +0e ATU Stats 001f
> 0f Priority override table 0f00
> 10 Reserved 0000
> 11 Reserved 0000
>
> Thanks in advance
> Etienne
next prev parent reply other threads:[~2023-03-12 12:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-12 5:41 mv88e6xxx / MV88E6176 + VLAN-aware unusable in 5.15.98 (ok in 5.10.168) (resend) Etienne Champetier
2023-03-12 12:11 ` Tobias Waldekranz [this message]
2023-03-13 3:13 ` Etienne Champetier
2023-03-13 22:30 ` Vladimir Oltean
2023-03-15 2:35 ` Etienne Champetier
2023-03-15 9:23 ` Vladimir Oltean
2023-03-16 15:40 ` Marek Behún
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=87edpudv9c.fsf@waldekranz.com \
--to=tobias@waldekranz.com \
--cc=champetier.etienne@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=vladimir.oltean@nxp.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).