felix_update...021q_rx_rule(9)

💖 NAME 💖

bestie, welcome to the felix_update...021q_rx_rule(9) page from the Kernel API Manual 🫶 — the actual name is:

felix_update_tag_8021q_rx_rule — Update VCAP ES0 tag_8021q rule after vlan_filtering change ✨

🎀 SYNOPSIS 🎀

void felix_update_tag_8021q_rx_rule (struct ocelot_vcap_filter
*outer_tagging_rule , bool vlan_filtering );

🦋 ARGUMENTS 🦋

• outer_tagging_rule — Pointer to VCAP filter on which the update is performed 💅
• vlan_filtering — Current bridge VLAN filtering setting ⭐

🌸 DESCRIPTION 🌸

okay so source port identification for tag_8021q is done using VCAP ES0 rules on the CPU port(s) 👑 The ES0 tag B (inner tag from the packet) can be configured as either:

• push_inner_tag=0: the inner tag is never pushed into the frame (and we lose info about the classified VLAN). This is good when the classified VLAN is a discardable quantity for the software RX path: it is either set to OCELOT_STANDALONE_PVID, or to ocelot_vlan_unaware_pvid(bridge). 🍓
• push_inner_tag=1: the inner tag is always pushed. This is good when the classified VLAN is not a discardable quantity (the port is under a VLAN-aware bridge, and software needs to continue processing the packet in the same VLAN as the hardware). 🔥

the way that the point is: what is good for a VLAN-unaware port is not good for a VLAN-aware port, and vice versa 😭 Thus, the RX tagging rules must be kept in sync with the VLAN filtering state of the port. no cap 💜

🌈 SEE ALSO 🌈

• Kernel file ./drivers/net/dsa/ocelot/felix.c 🦋

mwah 💋 — this cutie came from ./drivers/net/dsa/ocelot, dated October 2026, and it’s literally the felix_update...021q_rx_rule(9) page. periodt 🎀