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: