From: bugzilla@dpdk.org
To: dev@dpdk.org
Subject: [DPDK/ethdev Bug 1677] E810 VLAN Stripping Offload broken with multiple RX queues
Date: Mon, 17 Mar 2025 07:40:32 +0000 [thread overview]
Message-ID: <bug-1677-3@http.bugs.dpdk.org/> (raw)
[-- Attachment #1: Type: text/plain, Size: 4028 bytes --]
https://bugs.dpdk.org/show_bug.cgi?id=1677
Bug ID: 1677
Summary: E810 VLAN Stripping Offload broken with multiple RX
queues
Product: DPDK
Version: 24.11
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: roemerthorben@web.de
Target Milestone: ---
## Overwiew
When using net/ice with E810 NICs and multiple RX queues, hardware VLAN
stripping seems to be working inconsistently, leading to missing VLAN
information for some received packets.
## Setup + Build
* x86-build on Debian Bookworm
* DPDK 24.11 and current main (2025-03-14,
7d6c28c9199351805e693e9b8f58f60e6f51c2ab) were tested
* E810 NIC with firmware 4.0 and 4.6 were tested
* ice DDP (1.3.30.0, ICE OS Default Package (double VLAN mode)) and (1.3.46.0,
ICE COMMS package (double VLAN mode)) were tested
* AVX2 Vector Rx is chosen by ice driver ("ICE_DRIVER: ice_set_rx_function():
Using AVX2 OFFLOAD Vector Rx (port 0)")
## Steps to Reproduce
1. Start testpmd with two rx queues:
./dpdk-testpmd -- -i --enable-hw-vlan-strip --rxq 2 --txq 2
testpmd> show port 0 rx_offload configuration
Rx Offloading Configuration of port 0 :
Port : VLAN_STRIP RSS_HASH
Queue[ 0] : VLAN_STRIP RSS_HASH
Queue[ 1] : VLAN_STRIP RSS_HASH
testpmd> set verbose 1
Change verbose level from 0 to 1
testpmd> start
2. Send multiple IPv4+UDP packets with VLAN 100 and different destination IP
addresses until packets for both queues are received. testpmd output:
src=XX:XX:XX:XX:XX:XX - dst=YY:YY:YY:YY:YY:YY - pool=mb_pool_0 - type=0x0800 -
length=60 - nb_segs=1 - RSS hash=0xfd40ac19 - RSS queue=0x1 - VLAN tci=0x64 -
hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_UDP - sw ptype: L2_ETHER L3_IPV4
L4_UDP - l2_len=14 - l3_len=20 - l4_len=8 - Destination UDP port=1234 -
Receive queue=0x1
ol_flags: RTE_MBUF_F_RX_VLAN RTE_MBUF_F_RX_RSS_HASH 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_GOOD
src=XX:XX:XX:XX:XX:XX - dst=YY:YY:YY:YY:YY:YY - pool=mb_pool_0 - type=0x0800 -
length=60 - nb_segs=1 - RSS hash=0x91fa772a - RSS queue=0x0 - hw ptype:
L2_ETHER L3_IPV4_EXT_UNKNOWN L4_UDP - sw ptype: L2_ETHER L3_IPV4 L4_UDP -
l2_len=14 - l3_len=20 - l4_len=8 - Destination UDP port=1234 - Receive
queue=0x0
ol_flags: RTE_MBUF_F_RX_RSS_HASH RTE_MBUF_F_RX_L4_CKSUM_GOOD
RTE_MBUF_F_RX_IP_CKSUM_GOOD RTE_MBUF_F_RX_OUTER_L4_CKSUM_GOOD
3. The mbuf for the packet received by queue 0x1 (first packet displayed here)
is looking as expected:
* `RTE_MBUF_F_RX_VLAN_STRIPPED` is set in `ol_flags`
* `VLAN tci` is 0x64=100
* `type` (ethertype) is 0x0800 becase VLAN header was stripped, leaving
0x0800=IPv4.
The mbuf for the second packet, received by queue 0x0, looks broken: `ol_flags`
does not contain `RTE_MBUF_F_RX_VLAN_STRIPPED` and `VLAN tci` is not set, which
indicates that the VLAN was not stripped. But `type` (ethertype) is still
0x0800, as if the VLAN header had been stripped. If no VLAN was stripped, the
type should be 0x8100. If the VLAN was stripped, `ol_flags` and `VLAN tci`
should be set. This inconsistency means that the VLAN information was
completely lost and can not be recovered by the userspace application for
packets received by queue 0x0.
## Additional Information
The issue is also present in a custom user space application, so it seems
unlikely to be an error in testpmd.
According to ice.ini in docs/, the driver should fully support VLAN Stripping
even in vector paths.
The issue occurs since commit
http://git.dpdk.org/dpdk/commit/drivers/net/ice?id=882ed13a2a8c3b5cba48c15af710bf09d445094a.
Before that (or if reverted), no VLAN is stripped but the mbuf is consistent at
least (type 0x8100).
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #2: Type: text/html, Size: 6018 bytes --]
reply other threads:[~2025-03-17 7:40 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-1677-3@http.bugs.dpdk.org/ \
--to=bugzilla@dpdk.org \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).