dsa_software...aware_bridge(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

dsa_software_untag_vlan_unaware_bridge(9) πŸ’…

okay bestie, welcome to this page from the Kernel API Manual β€” manual name folded in right here, no awkward header repeat, we're keeping it cute πŸŽ€

✨ NAME ✨

dsa_software_untag_vlan_unaware_bridge β€” software untagging for VLAN-unaware bridge. That's the whole vibe: it untags, it's software, and the bridge is VLAN-unaware. Periodt.

πŸ¦‹ SYNOPSIS πŸ¦‹

void dsa_software_untag_vlan_unaware_bridge (struct sk_buff *skb , struct net_device *br , u16 vid );

πŸ’– ARGUMENTS πŸ’–

  • skb β€” pointer to the received socket buffer (the packet, bestie).
  • br β€” pointer to the bridge upper interface of the ingress port.
  • vid β€” the parsed VID from the packet.

πŸ”₯ DESCRIPTION πŸ”₯

The bridge ignores all VLAN tags. Software like STP/PTP may not β€” it may run on the plain port, or on a VLAN upper interface. iykyk 🌈

Maybe packets are coming to software as tagged with a driver-defined VID which is NOT equal to the PVID of the bridge port. And because the bridge is VLAN-unaware, its configuration should NOT be committed to hardware. DSA needs a method for this private VID to be communicated by software to it, and if packets are tagged with it, software-untag them. Note: the private VID may be different per bridge, to support the FDB isolation use case. Slay for isolation, honestly 🫢

FIXME: this is currently implemented based on the broken assumption that the "private VID" used by the driver in VLAN-unaware mode is equal to the bridge PVID. It should not be, except for a coincidence; the bridge PVID is irrelevant to the data path in the VLAN-unaware mode. Thus, the VID that this function removes is wrong.

Okay so that FIXME is not a cute little quirk β€” the VID this function removes is wrong. The whole assumption is lowkey broken, no cap. 😭

All users of ds->untag_bridge_pvid should fix their drivers, if necessary, to make the two independent. Only then, if there still remains a need to strip the private VID from packets, then a new ds->ops->get_private_vid API shall be introduced to communicate to DSA what this VID is, which needs to be stripped here. That's the plan, periodt πŸ’…

🌈 SEE ALSO 🌈

Kernel file ./net/dsa/tag.h, dsa_software_untag_vlan_aware_bridge(9), dsa_software_vlan_untag(9), module_dsa_tag_drivers(9), module_dsa_tag_driver(9) πŸ’–


Signed off from ./net/dsa Β· October 2026 Β· dsa_software...aware_bridge(9) β€” bye bestie, go fix those drivers 🧚✨

πŸ“¦ where this page comes from