As of 1.3.0, it appears that the fixed parser only supports a single VLAN tag on an ethernet frame. To extend support of an additional tag for common QinQ ethertype (0x88a8, 0x9100), one must add them as flex parsed headers. However, nv_parse_vlan does not appear to be a valid transition from these flex headers resulting in compilation failure.
In this scenario, what would be the recommended approach to add QinQ support to the parser in order to take advantage of built in anchors and standard metadata such as “last_l2_ether_type”.
Additionally, it seems like the use of a custom L2 seems to be limited to transitioning from nv_parse_ethernet only, as adding an additional transition to nv_parse_vlan does not compile. Is there a known workaround to this compilation failure? Is the expectation to use flex parsing for a single VLAN tag? If so, how does this impact the VLAN anchor and last_l2_ethertype?
You’ve hit a current limitation of the DOCA TA parser: flex nodes can only be reached from fixed states (e.g. via @nv_transition_from("nv_parse_ethernet", …)), and there is no supported way to transition from a flex header back into nv_parse_vlan, so that compilation failure is expected.
For standard QinQ with 0x8100/0x88A8, the recommendation is to let the fixed “MAC w VLAN” node handle both tags so you can keep using std_meta.last_l2_ether_type and the VLAN anchors.
For non‑standard TPIDs like 0x9100, you need to model the outer tag as a flex header, then jump directly to nv_parse_ipv4 / nv_parse_ipv6 / nv_parse_mpls (not nv_parse_vlan), and if you still rely on last_l2_ether_type later in the pipeline you can correct it explicitly in control with nv_set_l2_ethertype(headers, inner_ether_type).