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.moha...@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.
