Most drivers are silently ignoring 'has_vlan' rte_flow match criteria

https://bugs.dpdk.org/show_bug.cgi?id=958

            Bug ID: 958
           Summary: Most drivers are silently ignoring 'has_vlan' rte_flow
                    match criteria
           Product: DPDK
           Version: 21.11
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: ethdev
          Assignee: [email protected]
          Reporter: [email protected]

Target Milestone: ---

VLAN presence attribute 'has_vlan' in the 'struct rte_flow_item_eth' was introduced by commit:
09315fc83861 ("ethdev: add VLAN attributes to ethernet and VLAN items")

However, AFAICT, to the date, only 2 drivers actually supports that attribute. These are mlx5 and sfc.

All other drivers (i40e, bnxt, ...) are not checking 'has_vlan' at all. Since the attribute is not checked by the drivers, it's not possible to identify if the particular driver supports it or not. Driver will just accept the structure in most cases and validation will pass.

Documentation at https://doc.dpdk.org/guides/nics/overview.html says that most of the drivers supports 'eth' rte_flow item, but that is clearly wrong, since they doesn't support 'has_vlan' flag. All of them, except for mlx5 and sfc should be marked as partial support (P).

This problem makes the 'has_vlan' attribute practically unusable by any application, e.g. OVS, which is not designed to work with a particular driver, but needs to support a large variety of different hardware.

From the OVS perspective, we seem to need the 'has_vlan' functionality in order to fix the vlan matching bug, but we can not use it, because that will introduce a lot of issues with drivers that silently ignore this flow attribute:
https://patchwork.ozlabs.org/project/openvswitch/list/?series=284866

On a side note, rte_flow_item_eth.{src, dst} was supposed to be removed in 21.11 release (according to the deprecation notice), but these fields are still in the structure and most drivers are still using them.

You are receiving this mail because:
You are the assignee for the bug.