[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4e7a20a8-5911-4233-b93a-d03693019272@altera.com>
Date: Mon, 13 Oct 2025 20:18:24 +0530
From: "G Thomas, Rohan" <rohan.g.thomas@...era.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Rohan G Thomas via B4 Relay
<devnull+rohan.g.thomas.altera.com@...nel.org>,
Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>, Maxime Coquelin
<mcoquelin.stm32@...il.com>, Alexandre Torgue
<alexandre.torgue@...s.st.com>, Jose Abreu <Jose.Abreu@...opsys.com>,
Rohan G Thomas <rohan.g.thomas@...el.com>, netdev@...r.kernel.org,
linux-stm32@...md-mailman.stormreply.com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Matthew Gerlach <matthew.gerlach@...era.com>,
"Ng, Boon Khai" <boon.khai.ng@...era.com>
Subject: Re: [PATCH net v2 2/2] net: stmmac: Consider Tx VLAN offload tag
length for maxSDU
Hi Jakub,
On 9/26/2025 10:17 PM, G Thomas, Rohan wrote:
> Hi Jakub,
>
> On 9/26/2025 7:22 AM, Jakub Kicinski wrote:
>> On Thu, 25 Sep 2025 16:33:21 +0530 G Thomas, Rohan wrote:
>>> While testing 802.1AD with XGMAC hardware using a simple ping test, I
>>> observed an unexpected behavior: the hardware appears to insert an
>>> additional 802.1Q CTAG with VLAN ID 0. Despite this, the ping test
>>> functions correctly.
>>>
>>> Here’s a snapshot from the pcap captured at the remote end. Outer VLAN
>>> tag used is 100 and inner VLAN tag used is 200.
>>>
>>> Frame 1: 110 bytes on wire (880 bits), 110 bytes captured (880 bits)
>>> Ethernet II, Src: <src> (<src>), Dst: <dst> (<dst>)
>>> IEEE 802.1ad, ID: 100
>>> 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 0(unexpected)
>>> 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 200
>>> Internet Protocol Version 4, Src: 192.168.4.10, Dst: 192.168.4.11
>>> Internet Control Message Protocol
>>
>> And the packet arrives at the driver with only the .1Q ID 200 pushed?
>>
>
> Yes, the packet arrives the driver with only 802.1Q ID.
>
> [ 210.192912] stmmaceth 10830000.ethernet eth0: >>> frame to be
> transmitted:
> [ 210.192917] len = 46 byte, buf addr: 0x0000000067c78222
> [ 210.192923] 00000000: xx xx xx xx xx xx xx xx xx xx xx xx 81 00 00 c8
> [ 210.192928] 00000010: 08 06 00 01 08 00 06 04 00 02 46 9b 06 1b 5b b6
> [ 210.192931] 00000020: c0 a8 04 0a c8 a3 62 0e d7 04 c0 a8 04 0b
>> Indeed, that looks like a problem with the driver+HW interaction.
>> IDK what the right terminology is but IIRC VLAN 0 is not a real VLAN,
>> just an ID reserved for frames that don't have a VLAN ID but want to
>> use the priority field. Which explains why it "works", receiver just
>> ignores that tag. But it's definitely not correct because switches
>> on the network will no see the real C-TAG after the S-TAG is stripped.
>
> Yes, we are trying to figure out the right configuration for the driver
> so that the right tag is inserted by the driver for double and single
> VLANs. Based on the register configuration options for MAC_VLAN_Incl and
> MAC_Inner_VLAN_Incl registers and descriptor configuration options
> available, the hardware may not support simultaneous offloading of STAG
> for 802.1AD double-tagged packets and CTAG for 802.1Q single-tagged
> packets. If that is the case disable STAG insertion offloading may be
> the right approach.
>
> Best Regards,
> Rohan
I’ve aligned internally with Boon Khai and conducted further validation
across various configurations of the MAC_VLAN_Incl register and Tx
descriptors. Based on our analysis, it appears that the hardware appears
to not support simultaneous offloading of both S-TAG for double VLAN
(802.1AD) packets and C-TAG for single VLAN (802.1Q) packets.
As per the XGMAC databook: CSVL bit of MAC_VLAN_Incl register controls
the VLAN type of the tag inserted in 13th and 14th bytes and CSVL bit of
MAC_Inner_VLAN_Incl register controls the VLAN type of the tag inserted
in 17th and 18th bytes of the packet.
Currently driver is configured to insert only STAG for MAC_VLAN_Incl
register while the MAC_Inner_VLAN_Incl register is not configured.
However Tx descriptors are configured for both Outer and Inner tag for
802.1AD packets.
Current configuration used in the driver is ambiguous and not documented
in the databook. So we think it is more accurate to disable
NETIF_F_HW_VLAN_STAG_TX for DWMAC IPs. Please let us know if anyone has
concerns with this approach or if we might be missing some info.
Best Regards,
Rohan
Powered by blists - more mailing lists