iavf pmd vlan Issue: dpdk-22.11.0

iavf pmd vlan Issue: dpdk-22.11.0

[Amiya Ranjan Mohakud]

[-- Attachment #1: Type: text/plain, Size: 3356 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 4807 bytes --]

Re: iavf pmd vlan Issue: dpdk-22.11.0

[Amiya Ranjan Mohakud]

[-- Attachment #1: Type: text/plain, Size: 5480 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 8100 bytes --]

Re: iavf pmd vlan Issue: dpdk-22.11.0

[Amiya Ranjan Mohakud]

[-- Attachment #1: Type: text/plain, Size: 5479 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 8287 bytes --]