[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<MR1P264MB3681BFFDEB416E4919D4C22CF84F2@MR1P264MB3681.FRAP264.PROD.OUTLOOK.COM>
Date: Fri, 25 Oct 2024 15:18:13 +0000
From: Hervé Gourmelon <herve.gourmelon@...nops.com>
To: Vladimir Oltean <vladimir.oltean@....com>
CC: Andrew Lunn <andrew@...n.ch>, Florian Fainelli <f.fainelli@...il.com>,
Vivien Didelot <vivien.didelot@...il.com>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, Tobias Waldekranz <tobias@...dekranz.com>
Subject: RE: [PATCH 1/1] net: dsa: fix tag_dsa.c for untagged VLANs
Hello Vladimir, and thanks for the answer,
On Fri, Oct 25, 2024 at 02:18:48PM +0000, Vladimir Oltean wrote:
>> Trying to set up an untagged VLAN bridge on a DSA architecture of
>> mv88e6xxx switches, I realized that whenever I tried to emit a
>> 'From_CPU' or 'Forward' DSA packet, it would always egress with an
>> unwanted 802.1Q header on the bridge port.
>
>What does the link partner see? The packet with the 8021.Q tag or
>without it?
The link partner definitely sees the packets with the 802.1Q tags.
>The packet will always exit the Linux bridge layer as VLAN-tagged,
>because skb->offload_fwd_mark will be set*. It will appear with the VLAN
>tag in tcpdump, but it should not appear with the VLAN tag on the wire
>or on the other side, if the VLAN on the bridge port is egress-untagged.
>If you only see this in tcpdump, it is expected behavior and not a problem.
Agreed, and this also what I figured out. But even then, on the link partner,
I would keep seeing undesired 8021.Q tags in the incoming packets, until
I patched net/dsa/tag_dsa.c as mentioned earlier.
Turning to the Marvell distributor for support (Avnet Silica) I was also given a
hint that the Src_Tagged bit had something to do with the presence of the
IEEE tag with a 0x8100 Ether type.
Then again, this solution suits my needs (working on a set of 3 cascaded
MV88E6097 chipsets with an EtherType-DSA link to the CPU) but I won't
pretend I've tested it in other setups on other Marvell Link Street chipsets...
>*in turn, that is because we set tx_fwd_offload to true, and the bridge
>layer entrusts DSA that it will send the packet into the right VLAN.
>Hence the unconditional presence of the tag, and the reliance upon the
>port egress setting to strip it in hardware where needed.
I tried to figure out that part as well, but couldn't get it to work without
my patch. I tried to restrict my patch to 'From_CPU' packets at first, but
I would still occasionally get 'Forward' packets with the unwanted 802.1Q
tag on the link partner.
So in the end I'm sharing this, just in case someone else is stuck with the
same problem...
Thank you for your time.
Powered by blists - more mailing lists