From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1CD08468FD for ; Mon, 16 Jun 2025 18:35:39 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0CE084067D; Mon, 16 Jun 2025 18:35:37 +0200 (CEST) Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) by mails.dpdk.org (Postfix) with ESMTP id C96F5402BC for ; Mon, 16 Jun 2025 18:35:34 +0200 (CEST) Received: by mail-yb1-f169.google.com with SMTP id 3f1490d57ef6-e740a09eb00so3781069276.0 for ; Mon, 16 Jun 2025 09:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1750091734; x=1750696534; darn=dpdk.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=l6tMcQy9GBa6Rrrl4egmcTwKpJMddBq0ojsFm6FlDvI=; b=AFHBV75PqXqx+A6zxmTjF8KBBw5yAh2F0otWN55nZuP3UhkUw3v7pDMm16/3pDGm2N 4vHNEMOuMPaEnmY8CKfHnJLZUICgUASISj+yh63CUTerVMcc7iNQxxk7VadXpR3yk/AK NtAxyHrB9J7e2oshSJBCCAf5lo2QEPkiyIOgE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750091734; x=1750696534; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=l6tMcQy9GBa6Rrrl4egmcTwKpJMddBq0ojsFm6FlDvI=; b=OrGBhRKmXmhYgHjXHqzhAhuCbr0hCLkEnizoG1yPPO5+TkmLuXvTK21YwGsDW3tX1U 2KThjT0jo2RmHxoD0kWqBqbpnbfV+3yMRbTcmmmlH+ZZdGlEnOicX6IG8rTQ0DERzO3g 1e0yZcxlCk7XXaCKH9y26wsb2NJvFI6i8+Ah+hpqWkVDNdpPov4tZ35B4WkHhlqnO9k3 JP/xPAfTWHkjNraYnL34PLmROjs3LxU6gRWoRG91TZGPkr0dhMzY/CMWG/+qvLjiiXfK PIS6Sxh2bR+zl/uJJd9ROQnYVFQWzpsP6w9brlRTDTb7vXOJ01PXboZw0j41CRz4eduE ZCfA== X-Forwarded-Encrypted: i=1; AJvYcCWLKvpuFrCPesvrhrNgg2L47cLKP1258mf460WHo74ynffPZGK65w/WU+VejoPPpuJI+2L+Wg==@dpdk.org X-Gm-Message-State: AOJu0Yyg1mbUNum0C+jZkJ2Whj8kGmWSrdy90T7GinsTE/IlTBGanGc+ YsC1qMXpT9LJM9C0pzxxOB/OSS7/iD7HbcoSOiW7zNkAzz0jad86DmLsnkQ8tKLgGYn0zBkdesW 3ZJB3r0nUzly+Cv2FUTxMQlN3fIJjYvYpyo1MP/f+HoDoGriGOAOh4tDInbvK26l1/6EdESNaET lm7XDGysja3iM= X-Gm-Gg: ASbGncvG4vdh5D73W+dKGfEuH9XHLN7M+xuitMX1olkGFzjRFv4vbpQKCRuG5cZtVM5 tLZuzcyuojQeNBCAg79B7kkVAkXnlHMBWUyK+9zDql96JcwJXI8MO8IbVy9otdvdLA5pEBTlXuo 1wLFhNatj3TBx6RXtoKOmfDA0UbLtrBZLmvkU/uvV9OoBj X-Google-Smtp-Source: AGHT+IELNgLnpuu4ELGl5GO6TrX+h6f42IHMFOwwHrANLX5YR7KvH8PZ3g2WX5x0cf0dW36shtAlR1CNk70XWvoMg3A= X-Received: by 2002:a05:6902:e0b:b0:e82:403f:dd1b with SMTP id 3f1490d57ef6-e82403fdd8fmr9868135276.42.1750091733852; Mon, 16 Jun 2025 09:35:33 -0700 (PDT) MIME-Version: 1.0 From: Amiya Ranjan Mohakud Date: Mon, 16 Jun 2025 22:04:57 +0530 X-Gm-Features: AX0GCFsflkQopMhgy6Pkg-QeNl6xYQnVs57gmz8NDPBPwUhwxut_cgeKbblrkrs Message-ID: Subject: iavf pmd vlan Issue: dpdk-22.11.0 To: dev@dpdk.org, users@dpdk.org Cc: wenjing.qiao@intel.com, Amiya Ranjan Mohakud Content-Type: multipart/alternative; boundary="0000000000001f234d0637b2fc73" X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --0000000000001f234d0637b2fc73 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=C2=AE 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/e25c7ed114b296ddaa583427824acc30bcf9c85= d 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* --=20 This electronic communication and the information and any files transmitted= =20 with it, or attached to it, are confidential and are intended solely for=20 the use of the individual or entity to whom it is addressed and may contain= =20 information that is confidential, legally privileged, protected by privacy= =20 laws, or otherwise restricted from disclosure to anyone else. If you are=20 not the intended recipient or the person responsible for delivering the=20 e-mail to the intended recipient, you are hereby notified that any use,=20 copying, distributing, dissemination, forwarding, printing, or copying of= =20 this e-mail is strictly prohibited. If you received this e-mail in error,= =20 please return the e-mail to the sender, delete it from your computer, and= =20 destroy any printed copy of it. --0000000000001f234d0637b2fc73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
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 pac=
kets with vlan tags. Later I added some vlans using rte_eth_dev_vlan_filter=
() and I see that the vlan is getting stripped off =C2=A0for the incoming p=
ackets. 

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 Controlle=
r XL710 for 40GbE QSFP+ (rev 02)
3b:00.1 Ethernet controller: Intel Corp=
oration Ethernet Controller XL710 for 40GbE QSFP+ (rev 02)
i40e PF Drive=
r: Out of tree 2.20.12
Firmware: 9.00/9.40 
DPDK Version: 22.11.0
=


Observation/Analysis:

I could see that even af=
ter disabling RTE_ETH_RX_OFFLOAD_VLAN_STRIP offload flag, when I receive th=
e 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 strippi=
ng 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 re=
lease note https://doc.dpdk.org/guides/rel_notes/release_22_11.html. Still it=
 did not help.


       Intel=C2=AE Ethernet Converged Network =
Adapter XL710-QDA2 (2X40G)
=C2=A0 =C2=A0 Firmware version(PF): 9.00 0x80=
00ce86 1.3179.0
=C2=A0 =C2=A0 Device id (pf/vf): 8086:1583 / 8086:154c=C2=A0 =C2=A0 Driver version(out-tree): 2.20.12 (i40e)
=C2=A0 =C2=A0 D=
river 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.

<= pre style=3D"font-size:13px;color:rgb(0,0,0)">I picked the fix, but still i= t did not help.

Later when I debugged further, I found that the vf_c= ap_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 VIRTCHN= L_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_VLA= N_V2 as well. Can we mainstream it? If yes, please let me know so that I ca= n raise a pull request for it, if required.
Regards
Amiya


This ele= ctronic communication and the information and any files transmitted with it= , or attached to it, are confidential and are intended solely for the use o= f the individual or entity to whom it is addressed and may contain informat= ion that is confidential, legally privileged, protected by privacy laws, or= otherwise restricted from disclosure to anyone else. If you are not the in= tended recipient or the person responsible for delivering the e-mail to the= intended recipient, you are hereby notified that any use, copying, distrib= uting, dissemination, forwarding, printing, or copying of this e-mail is st= rictly 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. --0000000000001f234d0637b2fc73--