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);
Regards
Amiya



On Mon, Jun 16, 2025 at 10:04 PM 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.