Skip to contentSkip to conversation

E810 VLAN Stripping Offload broken with multiple RX queues

DPDK/ethdev Bug 1677 [email protected] 1 participant 2 messages Mar 17, 2025 – Oct 10, 2025

lore
Share & tools
lore

[email protected]

author
#0 lore raw

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: [email protected]
          Reporter: [email protected]

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).

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.