Created a ticket: https://bugs.dpdk.org/show_bug.cgi?id=1725
Sharing the patch for the same for quick look.( I know it can be better
modularised.)

diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index 656a4c6176..25d7924c31 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -1360,6 +1360,18 @@ iavf_dev_vlan_filter_set(struct rte_eth_dev
*dev, uint16_t vlan_id, int on)
                err = iavf_add_del_vlan_v2(adapter, vlan_id, on);
                if (err)
                        return -EIO;
+               /* Disable strip for i40e kernel driver which supports vlan v2
+                * VIRTCHNL OP
+                */
+               if (adapter->hw.mac.type == IAVF_MAC_XL710 ||
+                   adapter->hw.mac.type == IAVF_MAC_VF ||
+                   adapter->hw.mac.type == IAVF_MAC_X722_VF) {
+                       if (on && !(dev_conf->rxmode.offloads &
RTE_ETH_RX_OFFLOAD_VLAN_STRIP)) {
+                               err = iavf_disable_vlan_strip(adapter);
+                               if (err)
+                                       return -EIO;
+                       }
+               }
                return 0;
        }

@@ -1375,10 +1387,9 @@ iavf_dev_vlan_filter_set(struct rte_eth_dev
*dev, uint16_t vlan_id, int on)
         * change strip flag. To be consistent with dpdk side, disable strip
         * again.
         *
-        * For i40e kernel driver which supports vlan v2, dpdk will
invoke vlan v2
-        * related function, so it won't go through here.
         */
        if (adapter->hw.mac.type == IAVF_MAC_XL710 ||
+           adapter->hw.mac.type == IAVF_MAC_VF ||
            adapter->hw.mac.type == IAVF_MAC_X722_VF) {
                if (on && !(dev_conf->rxmode.offloads &
RTE_ETH_RX_OFFLOAD_VLAN_STRIP)) {
                        err = iavf_disable_vlan_strip(adapter);





Thanks
Amiya


On Mon, 16 Jun 2025 at 22:05, Amiya Ranjan Mohakud <
amiya-ranjan.mohakud@broadcom.com> wrote:

> Hi All,
>
> I'm encountering an issue with XL710 SR-IOV on KVM for VLAN packets with DPDK-22.11.0 version.
>
> *Issue Description:* I have disabled RTE_ETH_RX_OFFLOAD_VLAN_STRIP in rte_eth_conf and calling rte_eth_dev_configure and expecting my dpdk application to receive the packets with vlan tags. Later I added some vlans using rte_eth_dev_vlan_filter() and I see that the vlan is getting stripped off  for the incoming packets.
>
> *Setup Details:(KVM SR-IOV)*
>
> KVM Host: Ubuntu 20.04.6 LTS: kernel version: 5.4.0-216-generic #236-Ubuntu
> NIC: XL710
> 3b:00.0 Ethernet controller: Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ (rev 02)
> 3b:00.1 Ethernet controller: Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ (rev 02)
> i40e PF Driver: Out of tree 2.20.12
> Firmware: 9.00/9.40
> DPDK Version: 22.11.0
>
>
> *Observation/Analysis:*
>
> I could see that even after disabling RTE_ETH_RX_OFFLOAD_VLAN_STRIP offload flag, when I receive the packets, the mbuf offload flags (RTE_MBUF_F_RX_VLAN | RTE_MBUF_F_RX_VLAN_STRIPPED) are set inside the mbuf. This confirms that the driver is stripping off the vlans.
>
>
> I tried with recommended PF driver version for DPDK-22.11.0 as per https://mails.dpdk.org/archives/dev/2023-November/281700.html and DPDK-22.11 release note https://doc.dpdk.org/guides/rel_notes/release_22_11.html. Still it did not help.
>
>
>        Intel® Ethernet Converged Network Adapter XL710-QDA2 (2X40G)
>     Firmware version(PF): 9.00 0x8000ce86 1.3179.0
>     Device id (pf/vf): 8086:1583 / 8086:154c
>     Driver version(out-tree): 2.20.12 (i40e)
>     Driver version(in-tree): 5.15.0-46-generic (i40e)
>
>
> Upon debugging further, I came across a DPDK commit: https://github.com/DPDK/dpdk/commit/e25c7ed114b296ddaa583427824acc30bcf9c85d which says it sets the vlan_strip on in PF when we set vlan filter on VF.
>
> I picked the fix, but still it did not help.
>
> Later when I debugged further, I found that the vf_cap_flags is set to VIRTCHNL_VF_OFFLOAD_VLAN_V2 for the above PF driver and still it sets the vlan_strip on. I extended the dpdk commit for the VIRTCHNL_VF_OFFLOAD_VLAN_V2 case which fixed the issue.
>
>
> I just want to know if it's a known issue for the VIRTCHNL_VF_OFFLOAD_VLAN_V2 case. I understand it's a known issue for VIRTCHNL_VF_OFFLOAD_VLAN_V1 and dpdk has a fix for it.
> Do we need to add the fix for VIRTCHNL_VF_OFFLOAD_VLAN_V2 as well. Can we mainstream it? If yes, please let me know so that I can raise a pull request for it, if required.
>
> Regards
> *Amiya*
>
>
> This electronic communication and the information and any files
> transmitted with it, or attached to it, are confidential and are intended
> solely for the use of the individual or entity to whom it is addressed and
> may contain information that is confidential, legally privileged, protected
> by privacy laws, or otherwise restricted from disclosure to anyone else. If
> you are not the intended recipient or the person responsible for delivering
> the e-mail to the intended recipient, you are hereby notified that any use,
> copying, distributing, dissemination, forwarding, printing, or copying of
> this e-mail is strictly prohibited. If you received this e-mail in error,
> please return the e-mail to the sender, delete it from your computer, and
> destroy any printed copy of it.