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.