On Fri, 12 Jun 2026 16:14:11 +0800 Xingui Yang <[email protected]> wrote:
> The tx_vlan set command currently only accepts a VLAN ID in range > [0, 4095]. This patch adds support for an extended format that includes > 802.1p priority and CFI bits, allowing users to set the VLAN priority > tag when inserting VLAN headers in TX packets. > > The extended format is: > bit 0-11: VLAN ID (0-4095) > bit 12: CFI (Canonical Format Indicator) > bit 13-15: Priority (0-7, 802.1p CoS) > > This is consistent with the VLAN tag structure used by > rte_eth_dev_set_vlan_pvid() where the PVID field encodes VLAN ID, CFI > and priority in the same format. > > A new command line option --enable-vlan-priority is added to enable this > feature. By default, the feature is disabled to maintain backward > compatibility with existing users. When enabled, the > vlan_id_is_invalid() function allows any 16-bit value to pass, while the > full 16-bit value (including CFI and priority bits) is passed to the > driver for hardware VLAN insertion. > > Signed-off-by: Xingui Yang <[email protected]> > --- Having ability to set priority bits is good, and testpmd should allow it. The mbuf vlan_tci is already a full 16-bit TCI (priority/CFI/VID), and the TX insert path copies tx_vlan_id straight into it. So priority insert already works; the only thing in the way is the < 4096 check. Do you actually need a new option for this? Both of_push_vlan + of_set_vlan_pcp (rte_flow) and "tx_vlan set pvid" already let you set the priority bits today, with no new code. If you still want "tx_vlan set" itself to carry priority, I'd suggest a smaller change: relax only the TX insert validators and drop the option and the global. Don't touch rx_vft_set -- it feeds the VLAN filter, which only takes a VLAN ID and rejects > 4095 anyway, so the flag just turns a clear error into a confusing one. Either way, if the option stays, please document it, and add a release note. The commit message why the existing paths aren't enough.
