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 E3841A0505; Thu, 7 Apr 2022 19:05:05 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 923DA4068B; Thu, 7 Apr 2022 19:05:05 +0200 (CEST) Received: from mail-yw1-f180.google.com (mail-yw1-f180.google.com [209.85.128.180]) by mails.dpdk.org (Postfix) with ESMTP id E953840689 for ; Thu, 7 Apr 2022 19:05:03 +0200 (CEST) Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-2eb43ad7909so69218777b3.2 for ; Thu, 07 Apr 2022 10:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hFDFdRbliGHwfg4SveDEy8pRYqWYstXtnTy5bm+mqhA=; b=YHRTEXxVO0B0BK7vpjo8x6yWWsb07xaWStTzOqdoKAlMg5Ue7TJM8Sjn4qTXH17Ho+ VAfnFh3EHOzAzj9qL8mG5flEBtR6/tjtmrNN8qBBPpOMP01AX2rx1bxiu5hLaVfTFGD+ eLigGj2M261ekkOXu0g8w/XklSLN++W7HXycig4nofz5FqywUdQl+cI9vQxDMgHqvaV2 fzb+31zzXMU+zgx5sUd1RCM7z9M7pmefXEBvW4fPzbVbNGxa+r296eFS5JYe4hHkeeA2 t3swkg6VygaOROjcfd/GsNmHtUcwS2s/MsTkNY++WIOD1SGRbBrqzvDYVtn6DTZJ5MCO hW4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hFDFdRbliGHwfg4SveDEy8pRYqWYstXtnTy5bm+mqhA=; b=b8WG7o0rHQzDPE7RMBaWzUVh2kZCRqLYe9nvNddCZlQCi5y9xa9qFZ/vIZJTFm8HSb k9gUPebunj30Bo26OQ5Htey+LlPNZTOrdOoKqtWWlRbc6kclQFAfx7Nj2dxCN5HxQfWD mnWyzZySQqWz8EGrMneQ/FOI97jjcUUCqOf+Sx69sOpN9XQQxFVDUSMjpH3t4Y0avMIk R4DeDUoGXq4EQZmYh9mW9BsVuyjEiNAn9cpCoyMfI4deg4LnAX8HoH3F/NBcSuvDezNE oMeF7cJ9BvJGtDHAZ2alxe1waBw970a1hfV07NeBsI0ZDOvvwdsVE7IPswxYbVtYoETx rUCA== X-Gm-Message-State: AOAM53375UJ8xsZIPQXetisXQBQDj8nvTbTTlSbUkYMdQVLx1X0Qc9dv vJwUb2w6o+MXFtHg/2A3XP1c02EaZckKSykCKXgudPPo X-Google-Smtp-Source: ABdhPJx3eNbM70Nn18fcdhSIerUht3gViyO4QHC3ay0jVo+00UL5Sd9Yi7EBvpWyotJbptU0mBM6uIT2+OR7hT/O9nQ= X-Received: by 2002:a0d:f487:0:b0:2eb:54f5:3abf with SMTP id d129-20020a0df487000000b002eb54f53abfmr12700613ywf.141.1649351102998; Thu, 07 Apr 2022 10:05:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ben Magistro Date: Thu, 7 Apr 2022 13:04:52 -0400 Message-ID: Subject: Re: i40e QinQ Offload w/ NVM 8.40 not working To: dev@dpdk.org Cc: ben.magistro@trinitycyber.com, Stefan Baranoff Content-Type: multipart/alternative; boundary="0000000000009aad8505dc137ac9" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --0000000000009aad8505dc137ac9 Content-Type: text/plain; charset="UTF-8" Hello, We were able to narrow it down to a NVM change between 8.30 (v26.2) and 8.40 (v26.4). The release notes for v26.2 indicate the wrong NVM version. We are trying to reach out to Intel as well to report the issue and get additional assistance. If anyone can assist with that, it would be appreciated. Cheers, Ben On Mon, Apr 4, 2022 at 11:36 AM Ben Magistro wrote: > Hello, > > Wanted to follow up with some additional testing results. I believe this > is a bug at the NVM firmware level but still want someone else to confirm. > We can easily retest or change parameters of testpmd to provide additional > information if desired. In parallel to this we will be trying to reach out > to Intel and Dell (Intel branded card with firmware provided by Dell) to > report this bug for additional follow up. > > Device configuration: > traffic gen (trex) --> sw1 (basic vlan -- vl 200) --> sw2 (qinq push -- vl > 300) -- dut (testpmd) > > OS: CentOS 7.9 > DPDK 21.11 (different than initial report, used to move to a current > version and try to rule out other issues, but same issue) > testpmd cmd: sudo /tmp/dpdk-testpmd -c 0xffff -- -i --enable-hw-vlan > --enable-hw-vlan-strip --enable-hw-vlan-extend --enable-hw-qinq-strip > NVM version(s): 8.15 (working) and 8.40 (non-working) > > Offload configuration (these were the same under both 8.15 and 8.40 so > only providing one copy) > testpmd> show port 0 rx_offload configuration > Rx Offloading Configuration of port 0 : > Port : VLAN_STRIP QINQ_STRIP VLAN_FILTER VLAN_EXTEND > Queue[ 0] : VLAN_STRIP QINQ_STRIP VLAN_FILTER VLAN_EXTEND > > testpmd> show port 1 rx_offload configuration > Rx Offloading Configuration of port 1 : > Port : VLAN_STRIP QINQ_STRIP VLAN_FILTER VLAN_EXTEND > Queue[ 0] : VLAN_STRIP QINQ_STRIP VLAN_FILTER VLAN_EXTEND > > testpmd> show port 2 rx_offload configuration > Rx Offloading Configuration of port 2 : > Port : VLAN_STRIP QINQ_STRIP VLAN_FILTER VLAN_EXTEND > Queue[ 0] : VLAN_STRIP QINQ_STRIP VLAN_FILTER VLAN_EXTEND > > testpmd> show port 3 rx_offload configuration > Rx Offloading Configuration of port 3 : > Port : VLAN_STRIP QINQ_STRIP VLAN_FILTER VLAN_EXTEND > Queue[ 0] : VLAN_STRIP QINQ_STRIP VLAN_FILTER VLAN_EXTEND > > When running testpmd with the above cmdline parameters and then setting > "set fwd rxonly" we observe the following results with the different > firmwares. > 8.15 (working) > src=F8:F2:1E:31:96:D0 - dst=F8:F2:1E:31:96:D1 - type=0x0800 - > length=74 - nb_segs=1 - QinQ VLAN tci=0xc8, VLAN tci outer=0x12c - hw > ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_TCP - sw ptype: L2_ETHER L3_IPV4 > L4_TCP - l2_len=14 - l3_len=20 - l4_len=40 - Receive queue=0x0 > ol_flags: RTE_MBUF_F_RX_VLAN RTE_MBUF_F_RX_L4_CKSUM_GOOD > RTE_MBUF_F_RX_IP_CKSUM_GOOD RTE_MBUF_F_RX_VLAN_STRIPPED > RTE_MBUF_F_RX_QINQ_STRIPPED RTE_MBUF_F_RX_QINQ > RTE_MBUF_F_RX_OUTER_L4_CKSUM_UNKNOWN > > 8.40 (non working) > src=F8:F2:1E:31:96:D0 - dst=F8:F2:1E:31:96:D1 - type=0x8100 - > length=78 - nb_segs=1 - VLAN tci=0xc8 - hw ptype: L2_ETHER > L3_IPV4_EXT_UNKNOWN L4_TCP - sw ptype: L2_ETHER_VLAN L3_IPV4 L4_TCP - > l2_len=18 - l3_len=20 - l4_len=40 - Receive queue=0x0 > ol_flags: RTE_MBUF_F_RX_VLAN RTE_MBUF_F_RX_L4_CKSUM_GOOD > RTE_MBUF_F_RX_IP_CKSUM_GOOD RTE_MBUF_F_RX_VLAN_STRIPPED > RTE_MBUF_F_RX_OUTER_L4_CKSUM_UNKNOWN > > > Thanks, > > Ben > > On Fri, Apr 1, 2022 at 11:13 AM Ben Magistro wrote: > >> Hello, >> >> We recently needed to apply a firmware upgrade for some XXV710s to >> resolve a FEC issue (I'd have to find the details in email) but applied >> this same firmware to other nics (XL710s) to maintain a >> consistent baseline. In testing we have seen the NVM 8.40 resolve the FEC >> issue but it introduces an issue with QinQ offloading + stripping. When >> running NVM 8.15 (previous version), we could send QinQ traffic, and the >> nic would properly strip and store the values into vlan_tci and >> vlan_tci_outer as expected. When running NVM 8.40 (FEC fix version) >> sending QinQ traffic is only stripping the inner tag. The code we are >> using has not changed. >> >> I added some additional lines to drivers/net/i40e/i40e_rxtx.c to help >> troubleshoot this, specifically one to log the vlans and one to log >> ext_status. In comparing the two, ext_status is 0 under 8.40 while it is 1 >> under 8.15. This does correspond with not running the second layer >> processing code in the i40e_rxtx.c (line ~87). We will continue to >> investigate but would like to get this out there sooner and ask for >> assistance in confirming this behavior. >> >> This is a Dell based card so the firmware package used to >> update/downgrade the card is coming from Dell and not Intel directly. It >> is our assumption that the firmware in general should be pretty consistent >> between the two. >> >> Traffic is being generated by trex with the vlan nesting being pushed by >> some Juniper switches. Both vlan tags are 0x8100. >> >> OS: CentOS 7.9 >> DPDK: 20.08 (we know it's not supported anymore, but were trying to put >> off that upgrade until some other changes were also completed) >> NIC: i40e XL710 -- net_i40e / firmware 8.15 0x800096d0 20.0.17 >> >> If there are any additional details needed please let us know. >> >> Thanks, >> >> Ben >> > --0000000000009aad8505dc137ac9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

We were able to narrow it down t= o a NVM change between 8.30 (v26.2) and 8.40 (v26.4).=C2=A0 The release not= es for v26.2 indicate the wrong NVM version.=C2=A0 We are trying to reach o= ut to Intel as well to report the issue and get additional assistance.=C2= =A0 If anyone can assist with that, it would be appreciated.

=
Cheers,

Ben

On Mon, Apr 4, 2022 = at 11:36 AM Ben Magistro <koncept1= @gmail.com> wrote:
Hello,

Wanted to follow up w= ith some additional testing results.=C2=A0 I believe this is a bug at the N= VM firmware level but still want someone=C2=A0else to confirm.=C2=A0 We can= easily retest or change parameters of testpmd to provide additional inform= ation if desired.=C2=A0 In parallel to this we will be trying to reach out = to Intel and Dell (Intel branded card with firmware provided by Dell) to re= port this bug for additional follow up.

Device con= figuration:
traffic gen (trex) --> sw1 (basic vlan -- vl 200) = --> sw2 (qinq push -- vl 300) -- dut (testpmd)

= OS: CentOS 7.9
DPDK 21.11 (different than initial report, used to= move to a current version and try to rule out other issues, but same issue= )
testpmd cmd:=C2=A0sudo /tmp/dpdk-testpmd -c 0xffff -- -i --enab= le-hw-vlan --enable-hw-vlan-strip --enable-hw-vlan-extend --enable-hw-qinq-= strip
NVM version(s): 8.15 (working) and 8.40 (non-working)
=

Offload configuration (these were the same under both 8= .15 and 8.40 so only providing one copy)
testpmd> show port 0 = rx_offload configuration
Rx Offloading Configuration of port 0 :
=C2= =A0 Port : VLAN_STRIP QINQ_STRIP VLAN_FILTER VLAN_EXTEND
=C2=A0 Queue[ 0= ] : VLAN_STRIP QINQ_STRIP VLAN_FILTER VLAN_EXTEND

testpmd> show p= ort 1 rx_offload configuration
Rx Offloading Configuration of port 1 :<= br>=C2=A0 Port : VLAN_STRIP QINQ_STRIP VLAN_FILTER VLAN_EXTEND
=C2=A0 Qu= eue[ 0] : VLAN_STRIP QINQ_STRIP VLAN_FILTER VLAN_EXTEND

testpmd> = show port 2 rx_offload configuration
Rx Offloading Configuration of por= t 2 :
=C2=A0 Port : VLAN_STRIP QINQ_STRIP VLAN_FILTER VLAN_EXTEND
=C2= =A0 Queue[ 0] : VLAN_STRIP QINQ_STRIP VLAN_FILTER VLAN_EXTEND

testpm= d> show port 3 rx_offload configuration
Rx Offloading Configuration = of port 3 :
=C2=A0 Port : VLAN_STRIP QINQ_STRIP VLAN_FILTER VLAN_EXTEND<= br>=C2=A0 Queue[ 0] : VLAN_STRIP QINQ_STRIP VLAN_FILTER VLAN_EXTEND

When running testpmd with the above cmdline parameter= s and then setting "set fwd rxonly" we observe the following resu= lts with the different firmwares.
8.15 (working)
=C2=A0 =C2= =A0 =C2=A0 src=3DF8:F2:1E:31:96:D0 - dst=3DF8:F2:1E:31:96:D1 - type=3D0x080= 0 - length=3D74 - nb_segs=3D1 - QinQ VLAN tci=3D0xc8, VLAN tci outer=3D0x12= c - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_TCP =C2=A0- sw ptype: L2_ETHE= R L3_IPV4 L4_TCP =C2=A0- l2_len=3D14 - l3_len=3D20 - l4_len=3D40 - Receive = queue=3D0x0
=C2=A0 =C2=A0 ol_flags: RTE_MBUF_F_RX_VLAN RTE_MBUF_F_RX_L4= _CKSUM_GOOD RTE_MBUF_F_RX_IP_CKSUM_GOOD RTE_MBUF_F_RX_VLAN_STRIPPED RTE_MBU= F_F_RX_QINQ_STRIPPED RTE_MBUF_F_RX_QINQ RTE_MBUF_F_RX_OUTER_L4_CKSUM_UNKNOW= N

8.40 (non working)
=C2=A0 =C2=A0 = =C2=A0src=3DF8:F2:1E:31:96:D0 - dst=3DF8:F2:1E:31:96:D1 - type=3D0x8100 - l= ength=3D78 - nb_segs=3D1 - VLAN tci=3D0xc8 - hw ptype: L2_ETHER L3_IPV4_EXT= _UNKNOWN L4_TCP =C2=A0- sw ptype: L2_ETHER_VLAN L3_IPV4 L4_TCP =C2=A0- l2_l= en=3D18 - l3_len=3D20 - l4_len=3D40 - Receive queue=3D0x0
=C2= =A0 =C2=A0=C2=A0ol_flags: RTE_MBUF_F_RX_VLAN RTE_MBUF_F_RX_L4_CKSUM_GOOD RT= E_MBUF_F_RX_IP_CKSUM_GOOD RTE_MBUF_F_RX_VLAN_STRIPPED RTE_MBUF_F_RX_OUTER_L= 4_CKSUM_UNKNOWN


Thanks,
=

Ben

On Fri, Apr 1, 2022 at 11:13 AM Ben Magistro = <koncept1@gmail.= com> wrote:
Hello,

We recently needed to apply a= firmware upgrade for some XXV710s to resolve a FEC issue (I'd have to = find the details in email) but applied this same firmware to other=C2=A0nic= s (XL710s) to maintain a consistent=C2=A0baseline.=C2=A0 In testing we have= seen the NVM 8.40 resolve the FEC issue but it introduces an issue with Qi= nQ offloading + stripping.=C2=A0 When running NVM 8.15 (previous version), = we could send QinQ traffic, and the nic would properly=C2=A0strip and store= the values into vlan_tci and vlan_tci_outer as expected.=C2=A0 When runnin= g NVM 8.40 (FEC fix version) sending QinQ traffic is only stripping the inn= er tag.=C2=A0 The code we are using has not changed.

I added some additional lines to drivers/net/i40e/i40e_rxtx.c to help tr= oubleshoot this, specifically one to log the vlans and one to log ext_statu= s.=C2=A0 In comparing the two, ext_status is 0 under 8.40 while it is 1 und= er 8.15.=C2=A0 This does correspond with not running the second layer proce= ssing code in the i40e_rxtx.c (line ~87).=C2=A0 We will continue to investi= gate but would like to get this out there=C2=A0sooner and ask for assistanc= e in confirming this behavior.

This is a Dell based card so t= he firmware package used to update/downgrade the card is coming from Dell a= nd not Intel directly.=C2=A0 It is our assumption that the firmware in gene= ral should be pretty consistent between the two.

Traffic is being generated by trex with the vlan nesting being pushed by= some Juniper switches.=C2=A0 Both vlan tags are 0x8100.

OS: CentOS 7.9
DPDK: 20.08 (we know it's not supported= anymore, but were trying to put off that upgrade until some other changes = were also completed)
NIC: i40e XL710 -- net_i40e / firmware 8.15 = 0x800096d0 20.0.17

If there are any additional det= ails needed please let us know.

Thanks,
=
Ben
--0000000000009aad8505dc137ac9--