[DPDK/ethdev Bug 1677] E810 VLAN Stripping Offload broken with multiple RX queues

[bugzilla@dpdk.org]

[-- 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 --]