|SUCCESS| net/ice: use configured outer TPID for VLAN filter in DVM

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/164458

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-05-27

Reviewing patch: net/ice: use configured outer TPID for VLAN filter in DVM

Commit: (patch file, no git sha available)
Author: KAVYA AV <kavyax.a.v at intel.com>
Subject: [PATCH] net/ice: use configured outer TPID for VLAN filter in DVM

Brief summary:
This patch modifies ice_vlan_filter_set() to use the user-configured
outer TPID (stored in pf->outer_ethertype) instead of the hardcoded
RTE_ETHER_TYPE_VLAN when programming VLAN filters in Double VLAN Mode.

> diff --git a/drivers/net/intel/ice/ice_ethdev.c b/drivers/net/intel/ice/ice_ethdev.c
> index 0f2e7aee14..eaf3354000 100644
> --- a/drivers/net/intel/ice/ice_ethdev.c
> +++ b/drivers/net/intel/ice/ice_ethdev.c
> @@ -5038,7 +5038,8 @@ static int
>  ice_vlan_filter_set(struct rte_eth_dev *dev, uint16_t vlan_id, int on)
>  {
>  	struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> -	struct ice_vlan vlan = ICE_VLAN(RTE_ETHER_TYPE_VLAN, vlan_id);
> +	/* Use the configured outer_ethertype instead of hardcoded 0x8100 */
> +	struct ice_vlan vlan = ICE_VLAN(pf->outer_ethertype, vlan_id);
>  	struct ice_vsi *vsi = pf->main_vsi;
>  	int ret;

Does this code properly handle the case where pf->outer_ethertype is
uninitialized? The commit message states that outer_ethertype defaults
to RTE_ETHER_TYPE_VLAN at initialization, but there is no validation here
to ensure pf is valid or that outer_ethertype has been set. Can
ice_vlan_filter_set() be called before the PF structure is fully
initialized? If so, should there be a check to verify pf->outer_ethertype
is non-zero before using it?

Is there a potential race condition between ice_vlan_tpid_set() updating
pf->outer_ethertype and ice_vlan_filter_set() reading it? If
ice_vlan_filter_set() can be called concurrently with ice_vlan_tpid_set(),
could this lead to inconsistent VLAN filter programming?