<div dir="ltr">Hi,A quick update on this issue.I can no longer reproduce the problem with DPDK 25.11.2 on the following NIC:<ul><li>Intel(R) Ethernet Network Adapter E810-CQDA2</li><li>Ethernet Controller E810-C for QSFP (rev 02)</li><li>Subsystem: Intel Ethernet Network Adapter E810-C-Q2</li></ul>However, the issue is still reproducible with DPDK 25.11.2 on:<ul><li>E810-C 100GbE Controller</li><li>Ethernet Controller E810-C for QSFP (rev 02)</li><li>Subsystem: Intel Ethernet 100G 2P E810-C Adapter</li></ul>The same test scenario was used in both cases.Thanks, Taras</div> <div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Feb 10, 2026 at 11:05 AM Taras Bilous <<a href="mailto:tarasb@interfacemasters.com">tarasb@interfacemasters.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi All, I am seeing multiple issues with net_ice where VLAN mode changes after a device reset or an ungraceful application exit, which then breaks RX VLAN offloading.The same NIC and the same DDP package behave correctly after a cold start, but switch to a different VLAN mode after either <code>port reset (or rte_eth_dev_reset())</code> in testpmd or after killing the application with SIGKILL. After that, VLAN tags appear to be stripped in hardware, but VLAN metadata is no longer delivered to vlan_tci in mbuf structure.<div>My setup is the following:<div>Debian Bookworm</div><div>Ethernet controller: Intel(R) Ethernet Controller E810-C for QSFP Firmware (NVM): 4.91 and 4.51 were tested DDP: ICE COMMS Package 1.3.55.0 and 1.3.50.0 were tested DPDK: 25.11First scenario: port reset in testpmd <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">:~$ sudo ./DPDK/dpdk-25.11.0/dpdk-25.11/build/app/dpdk-testpmd -l 0-15 -a 0000:04:00.0 -a 0000:04:00.1 -- -i EAL: Detected CPU lcores: 90 EAL: Detected NUMA nodes: 1 EAL: Detected static linkage of DPDK EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: Selected IOVA mode 'PA' ICE_INIT: ice_load_pkg_type(): Active package is: 1.3.55.0, ICE COMMS Package (double VLAN mode) ICE_INIT: ice_load_pkg_type(): Active package is: 1.3.55.0, ICE COMMS Package (double VLAN mode) Interactive-mode selected Warning: NUMA should be configured manually by using --port-numa-config and --ring-numa-config parameters along with --numa. testpmd: create a new mbuf pool <mb_pool_0>: n=267456, size=2176, socket=0 testpmd: preferred mempool ops selected: ring_mp_mc Configuring Port 0 (socket 0) ICE_DRIVER: ice_set_rx_function(): Using Vector AVX2 (port 0). Configuring Port 1 (socket 0) ICE_DRIVER: ice_set_rx_function(): Using Vector AVX2 (port 1). Port 0: link state change event Port 0: link state change event Checking link statuses... Done testpmd> port stop all Stopping ports... Checking link statuses... Done testpmd> port reset all Resetting ports... ETHDEV: Device with port_id=0 already stopped ICE_INIT: ice_load_pkg_type(): Active package is: 1.3.55.0, ICE COMMS Package (single VLAN mode) ETHDEV: Device with port_id=1 already stopped ICE_INIT: ice_load_pkg_type(): Active package is: 1.3.55.0, ICE COMMS Package (single VLAN mode)</blockquote> After this reset, RX VLAN offload no longer behaves correctly. VLAN tags are stripped from packets, but VLAN TCI information is missing in the received mbufs vlan_tci fields.Second scenario: killing the application with SIGKILL<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">:~$ sudo ./DPDK/dpdk-25.11.0/dpdk-25.11/build/app/dpdk-testpmd -l 0-15 -a 0000:04:00.0 -a 0000:04:00.1 -- -i EAL: Detected CPU lcores: 90 EAL: Detected NUMA nodes: 1 EAL: Detected static linkage of DPDK EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: Selected IOVA mode 'PA' ICE_INIT: ice_load_pkg_type(): Active package is: 1.3.55.0, ICE COMMS Package (double VLAN mode) ICE_INIT: ice_load_pkg_type(): Active package is: 1.3.55.0, ICE COMMS Package (double VLAN mode) Interactive-mode selected Warning: NUMA should be configured manually by using --port-numa-config and --ring-numa-config parameters along with --numa. testpmd: create a new mbuf pool <mb_pool_0>: n=267456, size=2176, socket=0 testpmd: preferred mempool ops selected: ring_mp_mc Configuring Port 0 (socket 0) ICE_DRIVER: ice_set_rx_function(): Using Vector AVX2 (port 0). Configuring Port 1 (socket 0) ICE_DRIVER: ice_set_rx_function(): Using Vector AVX2 (port 1). Port 0: link state change event Port 0: link state change event Checking link statuses... Done testpmd> Killed </blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">:~$ sudo ./DPDK/dpdk-25.11.0/dpdk-25.11/build/app/dpdk-testpmd -l 0-15 -a 0000:04:00.0 -a 0000:04:00.1 -- -i EAL: Detected CPU lcores: 90 EAL: Detected NUMA nodes: 1 EAL: Detected static linkage of DPDK EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: Selected IOVA mode 'PA' ICE_INIT: ice_load_pkg_type(): Active package is: 1.3.55.0, ICE COMMS Package (single VLAN mode) ICE_INIT: ice_load_pkg_type(): Active package is: 1.3.55.0, ICE COMMS Package (single VLAN mode) Interactive-mode selected Warning: NUMA should be configured manually by using --port-numa-config and --ring-numa-config parameters along with --numa. testpmd: create a new mbuf pool <mb_pool_0>: n=267456, size=2176, socket=0 testpmd: preferred mempool ops selected: ring_mp_mc Configuring Port 0 (socket 0) ICE_DRIVER: ice_set_rx_function(): Using Vector AVX2 (port 0). Configuring Port 1 (socket 0) ICE_DRIVER: ice_set_rx_function(): Using Vector AVX2 (port 1). Port 0: link state change event Port 0: link state change event Checking link statuses... Done testpmd> </blockquote><div> </div>At this point the behavior is the same as after port reset: RX VLAN offloading is broken. </div><div> The observed RX VLAN offloading behavior then is very similar to the issue described in the following bug report, where VLAN stripping works but metadata is missing:</div><div><a href="https://bugs.dpdk.org/show_bug.cgi?id=1677" target="_blank">https://bugs.dpdk.org/show_bug.cgi?id=1677</a> The trigger is different, but the resulting VLAN RX offload behavior appears to be the same. I can reproduce this reliably and can provide more logs or information if needed.</div><div> Best regards, Taras</div></div></div> </blockquote></div>