* E810 VLAN offload wrong behavior
@ 2025-07-11 11:28 Ernesto Ruffini
2025-07-14 0:03 ` Ivan Malov
0 siblings, 1 reply; 10+ messages in thread
From: Ernesto Ruffini @ 2025-07-11 11:28 UTC (permalink / raw)
To: users
[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]
Hi,
We found a strange behavior of the E810 VLAN offload.
We are running DPDK 24.11.2 with ice driver 1.15.4, firmware 4.60 and COMMS
DDP 1.3.46
The NIC receives an IPv4/UDP packet inside VLAN 300.
If we run dpdk-testpmd with a single queue, everything seems fine:
dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 -- -i
set verbose 5
port stop 0
port config 0 rx_offload vlan_strip on
port start 0
start
And the packet is correctly displayed:
src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 -
type=0x0800 - length=142 - nb_segs=1 - VLAN tci=0x12c - 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=5398 - Receive queue=0x0
ol_flags: RTE_MBUF_F_RX_VLAN 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
But if we use a different number of queues:
dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 -- -i --rxq=4 --txq=4
The VLAN is in fact removed, but there is no evidence of that:
src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 -
type=0x0800 - length=142 - nb_segs=1 - RSS hash=0xfae3080 - 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=5398 -
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
There was a bug in some previous versions of DPDK about E810 and VLAN
offload, but it was fixed.
Are we doing something wrong or is there a problem with the driver?
Thank you
Ernesto
[-- Attachment #2: Type: text/html, Size: 6108 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: E810 VLAN offload wrong behavior
2025-07-11 11:28 E810 VLAN offload wrong behavior Ernesto Ruffini
@ 2025-07-14 0:03 ` Ivan Malov
2025-07-14 7:48 ` Ernesto Ruffini
0 siblings, 1 reply; 10+ messages in thread
From: Ivan Malov @ 2025-07-14 0:03 UTC (permalink / raw)
To: Ernesto Ruffini; +Cc: users
[-- Attachment #1: Type: text/plain, Size: 2228 bytes --]
Hi Ernesto,
On Fri, 11 Jul 2025, Ernesto Ruffini wrote:
>
> Hi,
>
> We found a strange behavior of the E810 VLAN offload.
>
> We are running DPDK 24.11.2 with ice driver 1.15.4, firmware 4.60 and COMMS DDP 1.3.46
>
>
>
> The NIC receives an IPv4/UDP packet inside VLAN 300.
>
> If we run dpdk-testpmd with a single queue, everything seems fine:
>
>
>
> dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 -- -i
>
>
>
> set verbose 5
>
> port stop 0
>
> port config 0 rx_offload vlan_strip on
>
> port start 0
>
> start
>
>
>
> And the packet is correctly displayed:
>
> src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 - type=0x0800 - length=142 - nb_segs=1 - VLAN tci=0x12c - 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=5398 - Receive queue=0x0
>
> ol_flags: RTE_MBUF_F_RX_VLAN 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
>
>
>
> But if we use a different number of queues:
>
>
>
> dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 -- -i --rxq=4 --txq=4
It would be helpful to enable debug logs with EAL argument --log-level='.*',8
so that one can see which 'rx_pkt_burst' method gets selected by the driver.
Then one can inspect the implementation of that particular function to see
whether offloads are handled correctly.
Thank you.
>
>
>
> The VLAN is in fact removed, but there is no evidence of that:
>
>
>
> src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 - type=0x0800 - length=142 - nb_segs=1 - RSS hash=0xfae3080 - 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=5398 - 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
>
>
>
> There was a bug in some previous versions of DPDK about E810 and VLAN offload, but it was fixed.
>
> Are we doing something wrong or is there a problem with the driver?
>
>
>
> Thank you
>
> Ernesto
>
>
>
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: E810 VLAN offload wrong behavior
2025-07-14 0:03 ` Ivan Malov
@ 2025-07-14 7:48 ` Ernesto Ruffini
2025-07-14 12:49 ` Ivan Malov
0 siblings, 1 reply; 10+ messages in thread
From: Ernesto Ruffini @ 2025-07-14 7:48 UTC (permalink / raw)
To: 'Ivan Malov'; +Cc: users
[-- Attachment #1: Type: text/plain, Size: 2752 bytes --]
Hi Ivan,
Thanks for the hint.
I ran testpmd with the suggested parameter, but I cannot find where the
function gets selected.
I attach the full log here.
Thanks
Ernesto
-----Original Message-----
From: Ivan Malov <ivan.malov@arknetworks.am>
Sent: Monday, July 14, 2025 02:04
To: Ernesto Ruffini <eruffini@outsys.org>
Cc: users@dpdk.org
Subject: Re: E810 VLAN offload wrong behavior
Hi Ernesto,
On Fri, 11 Jul 2025, Ernesto Ruffini wrote:
>
> Hi,
>
> We found a strange behavior of the E810 VLAN offload.
>
> We are running DPDK 24.11.2 with ice driver 1.15.4, firmware 4.60 and
> COMMS DDP 1.3.46
>
>
>
> The NIC receives an IPv4/UDP packet inside VLAN 300.
>
> If we run dpdk-testpmd with a single queue, everything seems fine:
>
>
>
> dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 -- -i
>
>
>
> set verbose 5
>
> port stop 0
>
> port config 0 rx_offload vlan_strip on
>
> port start 0
>
> start
>
>
>
> And the packet is correctly displayed:
>
> src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 -
type=0x0800 - length=142 - nb_segs=1 - VLAN tci=0x12c - 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=5398 - Receive queue=0x0
>
> ol_flags: RTE_MBUF_F_RX_VLAN 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
>
>
>
> But if we use a different number of queues:
>
>
>
> dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 -- -i --rxq=4 --txq=4
It would be helpful to enable debug logs with EAL argument
--log-level='.*',8 so that one can see which 'rx_pkt_burst' method gets
selected by the driver.
Then one can inspect the implementation of that particular function to see
whether offloads are handled correctly.
Thank you.
>
>
>
> The VLAN is in fact removed, but there is no evidence of that:
>
>
>
> src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 -
> type=0x0800 - length=142 - nb_segs=1 - RSS hash=0xfae3080 - 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=5398 - 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
>
>
>
> There was a bug in some previous versions of DPDK about E810 and VLAN
offload, but it was fixed.
>
> Are we doing something wrong or is there a problem with the driver?
>
>
>
> Thank you
>
> Ernesto
>
>
>
>
>
[-- Attachment #2: log.txt --]
[-- Type: text/plain, Size: 48749 bytes --]
# dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 --log-level='.*',8 -- -i --rxq=4 --txq=4
EAL: lib.eal log level changed from info to debug
EAL: user1 log level changed from info to debug
EAL: user2 log level changed from info to debug
EAL: user3 log level changed from info to debug
EAL: user4 log level changed from info to debug
EAL: user5 log level changed from info to debug
EAL: user6 log level changed from info to debug
EAL: user7 log level changed from info to debug
EAL: user8 log level changed from info to debug
EAL: lib.node log level changed from info to debug
EAL: lib.graph log level changed from info to debug
EAL: lib.pipeline log level changed from info to debug
EAL: lib.table log level changed from info to debug
EAL: lib.pdump log level changed from notice to debug
EAL: lib.port log level changed from info to debug
EAL: lib.fib log level changed from info to debug
EAL: lib.vhost.fdset log level changed from info to debug
EAL: lib.vhost.config log level changed from info to debug
EAL: lib.vhost.data log level changed from warning to debug
EAL: lib.vhost.crypto log level changed from info to debug
EAL: lib.stack log level changed from notice to debug
EAL: lib.sched log level changed from info to debug
EAL: lib.reorder log level changed from info to debug
EAL: lib.rib log level changed from info to debug
EAL: lib.mldev log level changed from info to debug
EAL: lib.regexdev log level changed from info to debug
EAL: lib.rawdev log level changed from info to debug
EAL: lib.power log level changed from info to debug
EAL: lib.lpm log level changed from info to debug
EAL: lib.latencystats log level changed from info to debug
EAL: lib.ip_frag log level changed from info to debug
EAL: lib.gpudev log level changed from notice to debug
EAL: lib.eventdev.adapter.timer log level changed from notice to debug
EAL: lib.eventdev.adapter.timer.svc log level changed from notice to debug
EAL: lib.eventdev log level changed from info to debug
EAL: lib.efd log level changed from info to debug
EAL: lib.dmadev log level changed from info to debug
EAL: lib.cryptodev log level changed from info to debug
EAL: lib.compressdev log level changed from notice to debug
EAL: lib.cfgfile log level changed from info to debug
EAL: lib.bpf log level changed from info to debug
EAL: lib.bbdev log level changed from notice to debug
EAL: lib.acl log level changed from info to debug
EAL: lib.hash log level changed from info to debug
EAL: lib.hash.crc log level changed from info to debug
EAL: lib.hash.fbk log level changed from info to debug
EAL: lib.hash.thash log level changed from info to debug
EAL: lib.hash.gfni log level changed from info to debug
EAL: lib.hash.thash_poly log level changed from info to debug
EAL: lib.metrics log level changed from error to debug
EAL: lib.ethdev log level changed from info to debug
EAL: lib.net log level changed from info to debug
EAL: lib.mbuf log level changed from info to debug
EAL: lib.mempool log level changed from info to debug
EAL: lib.rcu log level changed from error to debug
EAL: lib.ring log level changed from info to debug
EAL: lib.telemetry log level changed from warning to debug
EAL: lib.argparse log level changed from info to debug
EAL: pmd.common.dpaax log level changed from error to debug
EAL: pmd.common.iavf log level changed from notice to debug
EAL: pmd.common.idpf.common log level changed from notice to debug
EAL: pmd.octeontx.mbox log level changed from notice to debug
EAL: bus.auxiliary log level changed from notice to debug
EAL: bus.cdx log level changed from notice to debug
EAL: bus.dpaa log level changed from notice to debug
EAL: bus.fslmc log level changed from notice to debug
EAL: bus.ifpga log level changed from notice to debug
EAL: bus.pci log level changed from notice to debug
EAL: bus.platform log level changed from notice to debug
EAL: bus.uacce log level changed from notice to debug
EAL: bus.vdev log level changed from notice to debug
EAL: bus.vmbus log level changed from notice to debug
EAL: pmd.common.cnxk.base log level changed from info to debug
EAL: pmd.common.cnxk.mbox log level changed from notice to debug
EAL: pmd.common.cnxk.crypto log level changed from notice to debug
EAL: pmd.common.cnxk.ml log level changed from notice to debug
EAL: pmd.common.cnxk.mempool log level changed from notice to debug
EAL: pmd.common.cnxk.nix log level changed from notice to debug
EAL: pmd.common.cnxk.flow log level changed from notice to debug
EAL: pmd.common.cnxk.event log level changed from notice to debug
EAL: pmd.common.cnxk.timer log level changed from notice to debug
EAL: pmd.common.cnxk.tm log level changed from notice to debug
EAL: pmd.common.cnxk.dpi log level changed from notice to debug
EAL: pmd.common.cnxk.rep log level changed from notice to debug
EAL: pmd.common.cnxk.esw log level changed from notice to debug
EAL: pmd.common.cnxk.ree log level changed from notice to debug
EAL: pmd.common.nfp.common log level changed from notice to debug
EAL: pmd.common.nitrox log level changed from notice to debug
EAL: pmd.qat.general log level changed from notice to debug
EAL: pmd.qat.dp log level changed from notice to debug
EAL: pmd.common.sfc_efx log level changed from notice to debug
EAL: mempool.dpaa log level changed from notice to debug
EAL: mempool.dpaa2 log level changed from notice to debug
EAL: pmd.mempool.octeontx log level changed from notice to debug
EAL: pmd.dma.dpaa log level changed from info to debug
EAL: pmd.dma.dpaa2 log level changed from info to debug
EAL: pmd.dma.hisilicon log level changed from info to debug
EAL: pmd.dma.idxd log level changed from warning to debug
EAL: pmd.dma.ioat log level changed from info to debug
EAL: pmd.dma.odm log level changed from notice to debug
EAL: pmd.dma.skeleton log level changed from info to debug
EAL: pmd.net.af_packet log level changed from notice to debug
EAL: pmd.net.ark log level changed from notice to debug
EAL: pmd.net.atlantic.init log level changed from notice to debug
EAL: pmd.net.atlantic.driver log level changed from notice to debug
EAL: pmd.net.avp.driver log level changed from notice to debug
EAL: pmd.net.axgbe.init log level changed from notice to debug
EAL: pmd.net.axgbe.driver log level changed from notice to debug
EAL: pmd.net.bnx2x.init log level changed from notice to debug
EAL: pmd.net.bnx2x.driver log level changed from notice to debug
EAL: pmd.net.bnxt.driver log level changed from notice to debug
EAL: pmd.net.bonding log level changed from notice to debug
EAL: pmd.net.cpfl.init log level changed from notice to debug
EAL: pmd.net.cpfl.driver log level changed from notice to debug
EAL: pmd.net.cxgbe log level changed from notice to debug
EAL: pmd.net.cxgbe.mbox log level changed from notice to debug
EAL: pmd.net.dpaa log level changed from notice to debug
EAL: pmd.net.dpaa2 log level changed from notice to debug
EAL: pmd.net.e1000.init log level changed from notice to debug
EAL: pmd.net.e1000.driver log level changed from notice to debug
EAL: pmd.net.ena.init log level changed from notice to debug
EAL: pmd.net.ena.driver log level changed from notice to debug
EAL: pmd.net.ena.com log level changed from warning to debug
EAL: pmd.net.enetc log level changed from notice to debug
EAL: pmd.net.enetfec log level changed from notice to debug
EAL: pmd.net.enic log level changed from info to debug
EAL: pmd.net.failsafe log level changed from notice to debug
EAL: pmd.net.fm10k.init log level changed from notice to debug
EAL: pmd.net.fm10k.driver log level changed from notice to debug
EAL: pmd.net.gve.driver log level changed from notice to debug
EAL: pmd.net.hinic log level changed from info to debug
EAL: pmd.net.hns3.init log level changed from notice to debug
EAL: pmd.net.hns3.driver log level changed from notice to debug
EAL: pmd.net.i40e.init log level changed from notice to debug
EAL: pmd.net.i40e.driver log level changed from notice to debug
EAL: pmd.net.iavf.init log level changed from notice to debug
EAL: pmd.net.iavf.driver log level changed from notice to debug
EAL: pmd.net.ice.init log level changed from notice to debug
EAL: pmd.net.ice.driver log level changed from notice to debug
EAL: pmd.net.idpf.init log level changed from notice to debug
EAL: pmd.net.idpf.driver log level changed from notice to debug
EAL: pmd.net.igc.init log level changed from info to debug
EAL: pmd.net.igc.driver log level changed from info to debug
EAL: pmd.net.ionic log level changed from notice to debug
EAL: pmd.net.ixgbe.init log level changed from notice to debug
EAL: pmd.net.ixgbe.driver log level changed from notice to debug
EAL: pmd.net.memif log level changed from notice to debug
EAL: pmd.net.netvsc.init log level changed from notice to debug
EAL: pmd.net.netvsc.driver log level changed from notice to debug
EAL: pmd.net.nfp.init log level changed from notice to debug
EAL: pmd.net.nfp.driver log level changed from notice to debug
EAL: pmd.net.nfp.cpp log level changed from notice to debug
EAL: pmd.net.ngbe.init log level changed from notice to debug
EAL: pmd.net.ngbe.driver log level changed from notice to debug
EAL: pmd.net.ntnic.general log level changed from info to debug
EAL: pmd.net.ntnic.nthw log level changed from info to debug
EAL: pmd.net.ntnic.filter log level changed from info to debug
EAL: pmd.net.ntnic.ntnic log level changed from info to debug
EAL: pmd.net.null log level changed from notice to debug
EAL: pmd.net.octeontx.mbox log level changed from notice to debug
EAL: pmd.net.octeontx.init log level changed from notice to debug
EAL: pmd.net.octeontx.driver log level changed from notice to debug
EAL: pmd.net.octeon_ep log level changed from notice to debug
EAL: pmd.net.pcap log level changed from notice to debug
EAL: pmd.net.pfe log level changed from notice to debug
EAL: pmd.net.qede.init log level changed from notice to debug
EAL: pmd.net.qede.driver log level changed from notice to debug
EAL: pmd.net.r8169.init log level changed from notice to debug
EAL: pmd.net.r8169.driver log level changed from notice to debug
EAL: pmd.net.ring log level changed from notice to debug
EAL: pmd.net.softnic log level changed from notice to debug
EAL: pmd.net.tap log level changed from notice to debug
EAL: pmd.net.thunderx.mbox log level changed from notice to debug
EAL: pmd.net.thunderx.init log level changed from notice to debug
EAL: pmd.net.thunderx.driver log level changed from notice to debug
EAL: pmd.net.txgbe.init log level changed from notice to debug
EAL: pmd.net.txgbe.driver log level changed from notice to debug
EAL: pmd.net.txgbe.bp log level changed from notice to debug
EAL: pmd.net.vdev_netvsc log level changed from notice to debug
EAL: pmd.net.vhost log level changed from notice to debug
EAL: pmd.net.virtio.init log level changed from notice to debug
EAL: pmd.net.virtio.driver log level changed from notice to debug
EAL: pmd.net.vmxnet3.init log level changed from notice to debug
EAL: pmd.net.vmxnet3.driver log level changed from notice to debug
EAL: pmd.net.zxdh.driver log level changed from notice to debug
EAL: pmd.net.zxdh.rx log level changed from notice to debug
EAL: pmd.net.zxdh.tx log level changed from notice to debug
EAL: pmd.net.zxdh.msg log level changed from notice to debug
EAL: pmd.raw.cnxk_bphy.bphy log level changed from info to debug
EAL: pmd.raw.cnxk_gpio.gpio log level changed from info to debug
EAL: pmd.raw.cnxk_rvu_lf.rvu_lf log level changed from info to debug
EAL: pmd.raw.dpaa2.cmdif log level changed from info to debug
EAL: pmd.raw.gdtc log level changed from notice to debug
EAL: pmd.raw.ntb log level changed from info to debug
EAL: pmd.raw.skeleton log level changed from info to debug
EAL: pmd.crypto.bcmfs.config log level changed from notice to debug
EAL: pmd.crypto.bcmfs.fp log level changed from notice to debug
EAL: pmd.crypto.caam log level changed from notice to debug
EAL: pmd.crypto.ccp log level changed from notice to debug
EAL: pmd.crypto.dpaa log level changed from notice to debug
EAL: pmd.crypto.dpaa2 log level changed from notice to debug
EAL: pmd.crypto.ionic log level changed from notice to debug
EAL: pmd.crypto.null log level changed from info to debug
EAL: pmd.crypto.octeontx log level changed from notice to debug
EAL: pmd.crypto.openssl log level changed from info to debug
EAL: pmd.crypto.scheduler log level changed from info to debug
EAL: pmd.crypto.virtio.init log level changed from notice to debug
EAL: pmd.crypto.virtio.session log level changed from notice to debug
EAL: pmd.crypto.virtio.rx log level changed from notice to debug
EAL: pmd.crypto.virtio.tx log level changed from notice to debug
EAL: pmd.crypto.virtio.driver log level changed from notice to debug
EAL: pmd.compress.octeontx log level changed from info to debug
EAL: pmd.compress.zlib log level changed from info to debug
EAL: pmd.vdpa.ifcvf log level changed from notice to debug
EAL: pmd.vdpa.nfp.core log level changed from notice to debug
EAL: pmd.vdpa.nfp.vdpa log level changed from notice to debug
EAL: pmd.vdpa.sfc.driver log level changed from notice to debug
EAL: pmd.event.dlb2 log level changed from notice to debug
EAL: pmd.event.dpaa log level changed from notice to debug
EAL: pmd.event.dpaa2 log level changed from notice to debug
EAL: pmd.event.dsw log level changed from notice to debug
EAL: pmd.event.opdl.driver log level changed from info to debug
EAL: pmd.event.skeleton log level changed from info to debug
EAL: pmd.event.sw log level changed from notice to debug
EAL: pmd.event.octeontx log level changed from notice to debug
EAL: pmd.event.octeontx.timer log level changed from notice to debug
EAL: pmd.bb.acc.common log level changed from info to debug
EAL: pmd.bb.acc.acc100 log level changed from notice to debug
EAL: pmd.bb.acc.vrb log level changed from notice to debug
EAL: pmd.bb.fpga_5gnr_fec log level changed from notice to debug
EAL: pmd.bb.fpga_lte_fec log level changed from notice to debug
EAL: pmd.bb.la12xx log level changed from notice to debug
EAL: pmd.bb.null log level changed from notice to debug
EAL: pmd.bb.turbo_sw log level changed from notice to debug
EAL: pmd.power.kvm_vm.guest_channel log level changed from info to debug
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 0 on socket 1
EAL: Detected lcore 2 as core 12 on socket 0
EAL: Detected lcore 3 as core 12 on socket 1
EAL: Detected lcore 4 as core 1 on socket 0
EAL: Detected lcore 5 as core 1 on socket 1
EAL: Detected lcore 6 as core 13 on socket 0
EAL: Detected lcore 7 as core 13 on socket 1
EAL: Detected lcore 8 as core 2 on socket 0
EAL: Detected lcore 9 as core 2 on socket 1
EAL: Detected lcore 10 as core 14 on socket 0
EAL: Detected lcore 11 as core 14 on socket 1
EAL: Detected lcore 12 as core 3 on socket 0
EAL: Detected lcore 13 as core 3 on socket 1
EAL: Detected lcore 14 as core 15 on socket 0
EAL: Detected lcore 15 as core 15 on socket 1
EAL: Detected lcore 16 as core 4 on socket 0
EAL: Detected lcore 17 as core 4 on socket 1
EAL: Detected lcore 18 as core 16 on socket 0
EAL: Detected lcore 19 as core 16 on socket 1
EAL: Detected lcore 20 as core 5 on socket 0
EAL: Detected lcore 21 as core 5 on socket 1
EAL: Detected lcore 22 as core 17 on socket 0
EAL: Detected lcore 23 as core 17 on socket 1
EAL: Detected lcore 24 as core 6 on socket 0
EAL: Detected lcore 25 as core 6 on socket 1
EAL: Detected lcore 26 as core 18 on socket 0
EAL: Detected lcore 27 as core 18 on socket 1
EAL: Detected lcore 28 as core 7 on socket 0
EAL: Detected lcore 29 as core 7 on socket 1
EAL: Detected lcore 30 as core 19 on socket 0
EAL: Detected lcore 31 as core 19 on socket 1
EAL: Detected lcore 32 as core 8 on socket 0
EAL: Detected lcore 33 as core 8 on socket 1
EAL: Detected lcore 34 as core 20 on socket 0
EAL: Detected lcore 35 as core 20 on socket 1
EAL: Detected lcore 36 as core 9 on socket 0
EAL: Detected lcore 37 as core 9 on socket 1
EAL: Detected lcore 38 as core 21 on socket 0
EAL: Detected lcore 39 as core 21 on socket 1
EAL: Detected lcore 40 as core 10 on socket 0
EAL: Detected lcore 41 as core 10 on socket 1
EAL: Detected lcore 42 as core 22 on socket 0
EAL: Detected lcore 43 as core 22 on socket 1
EAL: Detected lcore 44 as core 11 on socket 0
EAL: Detected lcore 45 as core 11 on socket 1
EAL: Detected lcore 46 as core 23 on socket 0
EAL: Detected lcore 47 as core 23 on socket 1
EAL: Maximum logical cores by configuration: 128
EAL: Detected CPU lcores: 48
EAL: Detected NUMA nodes: 2
EAL: Checking presence of .so 'librte_eal.so.25.0'
EAL: Checking presence of .so 'librte_eal.so.25'
EAL: Checking presence of .so 'librte_eal.so'
EAL: Detected static linkage of DPDK
DPAA_BUS: rte_dpaa_bus_parse(): Parse device name (0000:4b:00.0)
DPAA2_BUS: rte_fslmc_parse(): Invalid device for matching (0000:4b:00.0).
EAL: Ask a virtual area of 0x7000 bytes
EAL: Virtual area found at 0x100000000 (size = 0x7000)
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
CDX_BUS: cdx_scan(): opendir failed: No such file or directory
DPAA_BUS: rte_dpaa_bus_scan(): >>
DPAA_BUS: DPAA Bus not present. Skipping.
DPAA2_BUS: rte_fslmc_scan(): DPAA2: DPRC not available
DPAA2_BUS: rte_fslmc_scan(): FSLMC Bus Not Available. Skipping (-22)
UACCE_BUS: open /sys/class/uacce failed!
EAL: Bus auxiliary wants IOVA as 'DC'
EAL: Bus cdx wants IOVA as 'DC'
EAL: Bus dpaa_bus wants IOVA as 'DC'
EAL: Bus fslmc wants IOVA as 'DC'
PCI_BUS: PCI driver net_ice for device 0000:4b:00.0 wants IOVA as 'PA'
EAL: Bus pci wants IOVA as 'PA'
EAL: Bus platform wants IOVA as 'DC'
EAL: Bus vdev wants IOVA as 'DC'
EAL: Bus dsa wants IOVA as 'DC'
EAL: Selected IOVA mode 'PA'
EAL: Probing VFIO support...
EAL: Module /sys/module/vfio not found! error 2 (No such file or directory)
EAL: VFIO modules not loaded, skipping VFIO support...
EAL: Ask a virtual area of 0x2e000 bytes
EAL: Virtual area found at 0x100007000 (size = 0x2e000)
EAL: Setting up physically contiguous memory...
EAL: Setting maximum number of open files to 262144
EAL: Detected memory type: socket_id:0 hugepage_sz:1073741824
EAL: Detected memory type: socket_id:1 hugepage_sz:1073741824
EAL: Creating 2 segment lists: n_segs:32 socket_id:0 hugepage_sz:1073741824
EAL: Ask a virtual area of 0x1000 bytes
EAL: Virtual area found at 0x100035000 (size = 0x1000)
EAL: Memseg list allocated at socket 0, page size 0x100000kB
EAL: Ask a virtual area of 0x800000000 bytes
EAL: Virtual area found at 0x140000000 (size = 0x800000000)
EAL: VA reserved for memseg list at 0x140000000, size 800000000
EAL: Ask a virtual area of 0x1000 bytes
EAL: Virtual area found at 0x940000000 (size = 0x1000)
EAL: Memseg list allocated at socket 0, page size 0x100000kB
EAL: Ask a virtual area of 0x800000000 bytes
EAL: Virtual area found at 0x980000000 (size = 0x800000000)
EAL: VA reserved for memseg list at 0x980000000, size 800000000
EAL: Creating 2 segment lists: n_segs:32 socket_id:1 hugepage_sz:1073741824
EAL: Ask a virtual area of 0x1000 bytes
EAL: Virtual area found at 0x1180000000 (size = 0x1000)
EAL: Memseg list allocated at socket 1, page size 0x100000kB
EAL: Ask a virtual area of 0x800000000 bytes
EAL: Virtual area found at 0x11c0000000 (size = 0x800000000)
EAL: VA reserved for memseg list at 0x11c0000000, size 800000000
EAL: Ask a virtual area of 0x1000 bytes
EAL: Virtual area found at 0x19c0000000 (size = 0x1000)
EAL: Memseg list allocated at socket 1, page size 0x100000kB
EAL: Ask a virtual area of 0x800000000 bytes
EAL: Virtual area found at 0x1a00000000 (size = 0x800000000)
EAL: VA reserved for memseg list at 0x1a00000000, size 800000000
EAL: Refined arch frequency 2800000000 to measured frequency 2793432645
EAL: TSC frequency is ~2793400 KHz
EAL: Main lcore 0 is ready (tid=7fc6c01b4c00;cpuset=[0])
EAL: lcore 1 is ready (tid=7fc6bb4d4400;cpuset=[1])
EAL: lcore 2 is ready (tid=7fc6bacd3400;cpuset=[2])
EAL: lcore 3 is ready (tid=7fc6ba4d2400;cpuset=[3])
EAL: lcore 4 is ready (tid=7fc6b9cd1400;cpuset=[4])
EAL: lcore 5 is ready (tid=7fc6b94d0400;cpuset=[5])
EAL: lcore 6 is ready (tid=7fc6b8ccf400;cpuset=[6])
EAL: lcore 7 is ready (tid=7fc6b84ce400;cpuset=[7])
EAL: lcore 8 is ready (tid=7fc6b7ccd400;cpuset=[8])
EAL: lcore 9 is ready (tid=7fc6b74cc400;cpuset=[9])
EAL: lcore 10 is ready (tid=7fc6b6ccb400;cpuset=[10])
EAL: lcore 11 is ready (tid=7fc6b64ca400;cpuset=[11])
EAL: lcore 12 is ready (tid=7fc6b5cc9400;cpuset=[12])
EAL: lcore 13 is ready (tid=7fc6b54c8400;cpuset=[13])
EAL: lcore 14 is ready (tid=7fc6b4cc7400;cpuset=[14])
EAL: lcore 15 is ready (tid=7fc6b44c6400;cpuset=[15])
EAL: lcore 16 is ready (tid=7fc6b3cc5400;cpuset=[16])
EAL: lcore 17 is ready (tid=7fc6b34c4400;cpuset=[17])
EAL: lcore 18 is ready (tid=7fc6b2cc3400;cpuset=[18])
EAL: lcore 19 is ready (tid=7fc6b24c2400;cpuset=[19])
EAL: lcore 20 is ready (tid=7fc6b1cc1400;cpuset=[20])
EAL: lcore 21 is ready (tid=7fc6b14c0400;cpuset=[21])
EAL: lcore 22 is ready (tid=7fc6b0cbf400;cpuset=[22])
EAL: lcore 23 is ready (tid=7fc6b04be400;cpuset=[23])
EAL: Trying to obtain current memory policy.
EAL: Setting policy MPOL_PREFERRED for socket 0
EAL: Restoring previous memory policy: 0
EAL: request: mp_malloc_sync
EAL: Heap on socket 0 was expanded by 1024MB
EAL: Allocated 2112 bytes of per-lcore data with a 64-byte alignment
PCI_BUS: PCI device 0000:4b:00.0 on NUMA socket 0
PCI_BUS: probe driver: 8086:1592 net_ice
PCI_BUS: PCI memory mapped at 0x2200000000
PCI_BUS: PCI memory mapped at 0x2202000000
PCI_BUS: Probe PCI driver: net_ice (8086:1592) device: 0000:4b:00.0 (socket 0)
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_0 allocated with physical address: 136364696896
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_1 allocated with physical address: 136364691648
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_2 allocated with physical address: 136364687424
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_3 allocated with physical address: 136364683200
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_4 allocated with physical address: 136364678976
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_5 allocated with physical address: 136364674752
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_6 allocated with physical address: 136364670528
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_7 allocated with physical address: 136364666304
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_8 allocated with physical address: 136364662080
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_9 allocated with physical address: 136364657856
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_10 allocated with physical address: 136364653632
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_11 allocated with physical address: 136364649408
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_12 allocated with physical address: 136364645184
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_13 allocated with physical address: 136364640960
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_14 allocated with physical address: 136364636736
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_15 allocated with physical address: 136364632512
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_16 allocated with physical address: 136364628288
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_17 allocated with physical address: 136364624064
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_18 allocated with physical address: 136364619840
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_19 allocated with physical address: 136364615616
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_20 allocated with physical address: 136364611392
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_21 allocated with physical address: 136364607168
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_22 allocated with physical address: 136364602944
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_23 allocated with physical address: 136364598720
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_24 allocated with physical address: 136364594496
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_25 allocated with physical address: 136364590272
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_26 allocated with physical address: 136364586048
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_27 allocated with physical address: 136364581824
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_28 allocated with physical address: 136364577600
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_29 allocated with physical address: 136364573376
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_30 allocated with physical address: 136364569152
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_31 allocated with physical address: 136364564928
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_32 allocated with physical address: 136364560704
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_33 allocated with physical address: 136364559552
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_34 allocated with physical address: 136364554304
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_35 allocated with physical address: 136364550080
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_36 allocated with physical address: 136364545856
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_37 allocated with physical address: 136364541632
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_38 allocated with physical address: 136364537408
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_39 allocated with physical address: 136364533184
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_40 allocated with physical address: 136364528960
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_41 allocated with physical address: 136364524736
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_42 allocated with physical address: 136364520512
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_43 allocated with physical address: 136364516288
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_44 allocated with physical address: 136364512064
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_45 allocated with physical address: 136364507840
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_46 allocated with physical address: 136364503616
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_47 allocated with physical address: 136364499392
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_48 allocated with physical address: 136364495168
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_49 allocated with physical address: 136364490944
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_50 allocated with physical address: 136364486720
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_51 allocated with physical address: 136364482496
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_52 allocated with physical address: 136364478272
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_53 allocated with physical address: 136364474048
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_54 allocated with physical address: 136364469824
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_55 allocated with physical address: 136364465600
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_56 allocated with physical address: 136364461376
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_57 allocated with physical address: 136364457152
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_58 allocated with physical address: 136364452928
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_59 allocated with physical address: 136364448704
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_60 allocated with physical address: 136364444480
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_61 allocated with physical address: 136364440256
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_62 allocated with physical address: 136364436032
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_63 allocated with physical address: 136364431808
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_64 allocated with physical address: 136364427584
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_65 allocated with physical address: 136364423360
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_66 allocated with physical address: 136364422208
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_67 allocated with physical address: 136364416960
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_68 allocated with physical address: 136364412736
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_69 allocated with physical address: 136364408512
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_70 allocated with physical address: 136364404288
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_71 allocated with physical address: 136364400064
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_72 allocated with physical address: 136364395840
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_73 allocated with physical address: 136364391616
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_74 allocated with physical address: 136364387392
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_75 allocated with physical address: 136364383168
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_76 allocated with physical address: 136364378944
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_77 allocated with physical address: 136364374720
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_78 allocated with physical address: 136364370496
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_79 allocated with physical address: 136364366272
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_80 allocated with physical address: 136364362048
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_81 allocated with physical address: 136364357824
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_82 allocated with physical address: 136364353600
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_83 allocated with physical address: 136364349376
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_84 allocated with physical address: 136364345152
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_85 allocated with physical address: 136364340928
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_86 allocated with physical address: 136364336704
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_87 allocated with physical address: 136364332480
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_88 allocated with physical address: 136364328256
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_89 allocated with physical address: 136364324032
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_90 allocated with physical address: 136364319808
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_91 allocated with physical address: 136364315584
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_92 allocated with physical address: 136364311360
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_93 allocated with physical address: 136364307136
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_94 allocated with physical address: 136364302912
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_95 allocated with physical address: 136364298688
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_96 allocated with physical address: 136364294464
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_97 allocated with physical address: 136364290240
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_98 allocated with physical address: 136364286016
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_99 allocated with physical address: 136364284864
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_100 allocated with physical address: 136364279616
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_101 allocated with physical address: 136364275392
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_102 allocated with physical address: 136364271168
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_103 allocated with physical address: 136364266944
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_104 allocated with physical address: 136364262720
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_105 allocated with physical address: 136364258496
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_106 allocated with physical address: 136364254272
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_107 allocated with physical address: 136364250048
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_108 allocated with physical address: 136364245824
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_109 allocated with physical address: 136364241600
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_110 allocated with physical address: 136364237376
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_111 allocated with physical address: 136364233152
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_112 allocated with physical address: 136364228928
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_113 allocated with physical address: 136364224704
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_114 allocated with physical address: 136364220480
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_115 allocated with physical address: 136364216256
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_116 allocated with physical address: 136364212032
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_117 allocated with physical address: 136364207808
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_118 allocated with physical address: 136364203584
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_119 allocated with physical address: 136364199360
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_120 allocated with physical address: 136364195136
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_121 allocated with physical address: 136364190912
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_122 allocated with physical address: 136364186688
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_123 allocated with physical address: 136364182464
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_124 allocated with physical address: 136364178240
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_125 allocated with physical address: 136364174016
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_126 allocated with physical address: 136364169792
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_127 allocated with physical address: 136364165568
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_128 allocated with physical address: 136364161344
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_129 allocated with physical address: 136364157120
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_130 allocated with physical address: 136364152896
ICE_DRIVER: ice_alloc_dma_mem(): memzone ice_dma_131 allocated with physical address: 136364148672
ICE_INIT: ice_load_pkg(): DDP package name: /lib/firmware/updates/intel/ice/ddp/ice.pkg
ICE_INIT: ice_load_pkg_type(): Active package is: 1.3.46.0, ICE COMMS Package (double VLAN mode)
ICE_INIT: ice_dev_init(): FW 7.6.1487673642 API 1.7
ICE_INIT: ice_dev_init(): lldp has already stopped
ICE_INIT: ice_dev_init(): Failed to init DCB
ICE_INIT: ice_flow_init(): Engine 4 disabled
ICE_DRIVER: ice_fdir_setup(): FDIR HW Capabilities: fd_fltr_guar = 1024, fd_fltr_best_effort = 14336.
ICE_INIT: ice_fdir_tx_queue_start(): >>
ICE_INIT: ice_fdir_rx_queue_start(): >>
ICE_DRIVER: __vsi_queues_bind_intr(): queue 0 is binding to vect 257
ICE_DRIVER: ice_fdir_setup(): FDIR setup successfully, with programming queue 0.
ICE_DRIVER: ice_update_vsi_stats(): ************** VSI[6] stats start **************
ICE_DRIVER: ice_update_vsi_stats(): rx_bytes: 0
ICE_DRIVER: ice_update_vsi_stats(): rx_unicast: 0
ICE_DRIVER: ice_update_vsi_stats(): rx_multicast: 0
ICE_DRIVER: ice_update_vsi_stats(): rx_broadcast: 0
ICE_DRIVER: ice_update_vsi_stats(): rx_discards: 0
ICE_DRIVER: ice_update_vsi_stats(): rx_unknown_protocol: 0
ICE_DRIVER: ice_update_vsi_stats(): tx_bytes: 0
ICE_DRIVER: ice_update_vsi_stats(): tx_unicast: 0
ICE_DRIVER: ice_update_vsi_stats(): tx_multicast: 0
ICE_DRIVER: ice_update_vsi_stats(): tx_broadcast: 0
ICE_DRIVER: ice_update_vsi_stats(): tx_discards: 0
ICE_DRIVER: ice_update_vsi_stats(): tx_errors: 0
ICE_DRIVER: ice_update_vsi_stats(): ************** VSI[6] stats end ****************
TELEMETRY: Attempting socket bind to path '/var/run/dpdk/rte/dpdk_telemetry.v2'
TELEMETRY: Socket creation and binding ok
TELEMETRY: Telemetry initialized ok
TELEMETRY: Attempting socket bind to path '/var/run/dpdk/rte/telemetry'
TELEMETRY: Socket creation and binding ok
TELEMETRY: Legacy telemetry socket initialized ok
Interactive-mode selected
MBUF: Registered dynamic flag RTE_MBUF_F_RX_RESTORE_INFO (fl=0x0) -> 23
testpmd: create a new mbuf pool <mb_pool_0>: n=331456, size=2176, socket=0
testpmd: preferred mempool ops selected: ring_mp_mc
testpmd: create a new mbuf pool <mb_pool_1>: n=331456, size=2176, socket=1
testpmd: preferred mempool ops selected: ring_mp_mc
EAL: Trying to obtain current memory policy.
EAL: Setting policy MPOL_PREFERRED for socket 1
EAL: Restoring previous memory policy: 4
EAL: request: mp_malloc_sync
EAL: Heap on socket 1 was expanded by 1024MB
Warning! port-topology=paired and odd forward ports number, the last port will pair with itself.
Configuring Port 0 (socket 0)
ETHDEV: Port 0 Rx offload RSS_HASH is not requested but enabled
ICE_INIT: ice_set_tx_function_flag(): Simple Tx can be enabled on Tx queue 0.
ICE_INIT: ice_set_tx_function_flag(): Simple Tx can be enabled on Tx queue 1.
ICE_INIT: ice_set_tx_function_flag(): Simple Tx can be enabled on Tx queue 2.
ICE_INIT: ice_set_tx_function_flag(): Simple Tx can be enabled on Tx queue 3.
ICE_INIT: ice_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are satisfied. Rx Burst Bulk Alloc function will be used on port=0, queue=0.
ICE_INIT: ice_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are satisfied. Rx Burst Bulk Alloc function will be used on port=0, queue=1.
ICE_INIT: ice_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are satisfied. Rx Burst Bulk Alloc function will be used on port=0, queue=2.
ICE_INIT: ice_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are satisfied. Rx Burst Bulk Alloc function will be used on port=0, queue=3.
ICE_INIT: ice_tx_queue_start(): >>
ICE_INIT: ice_tx_queue_start(): >>
ICE_INIT: ice_tx_queue_start(): >>
ICE_INIT: ice_tx_queue_start(): >>
ICE_INIT: ice_rx_queue_start(): >>
ICE_DRIVER: ice_program_hw_rx_queue(): Port (0) - Rx queue (0) is set with RXDID : 22
ICE_INIT: ice_rx_queue_start(): >>
ICE_DRIVER: ice_program_hw_rx_queue(): Port (0) - Rx queue (1) is set with RXDID : 22
ICE_INIT: ice_rx_queue_start(): >>
ICE_DRIVER: ice_program_hw_rx_queue(): Port (0) - Rx queue (2) is set with RXDID : 22
ICE_INIT: ice_rx_queue_start(): >>
ICE_DRIVER: ice_program_hw_rx_queue(): Port (0) - Rx queue (3) is set with RXDID : 22
ICE_INIT: ice_set_rx_function(): >>
ICE_DRIVER: ice_set_rx_function(): Using AVX2 OFFLOAD Vector Rx (port 0).
ICE_DRIVER: ice_set_tx_function(): Using avx2 Vector Tx (port 0).
ICE_DRIVER: ice_vsi_del_vlan_zero(): Failed to remove VLAN ID 0
ICE_DRIVER: __vsi_queues_bind_intr(): queue 1 is binding to vect 1
ICE_DRIVER: __vsi_queues_bind_intr(): queue 2 is binding to vect 1
ICE_DRIVER: __vsi_queues_bind_intr(): queue 3 is binding to vect 1
ICE_DRIVER: __vsi_queues_bind_intr(): queue 4 is binding to vect 1
Port 0: B4:96:91:D5:B6:C0
Checking link statuses...
Done
testpmd> ICE_DRIVER: ice_interrupt_handler(): OICR: link state change event
Port 0: link state change event
ICE_DRIVER: ice_interrupt_handler(): OICR: link state change event
Port 0: link state change event
testpmd> set verbose 5
Change verbose level from 0 to 5
testpmd> port stop 0
Stopping ports...
Checking link statuses...
Done
testpmd> ICE_DRIVER: ice_interrupt_handler(): OICR: link state change event
Port 0: link state change event
ICE_DRIVER: ice_interrupt_handler(): OICR: link state change event
Port 0: link state change event
testpmd> port config 0 rx_offload vlan_strip on
testpmd> port start 0
Configuring Port 0 (socket 0)
ICE_INIT: ice_set_tx_function_flag(): Simple Tx can be enabled on Tx queue 0.
ICE_INIT: ice_set_tx_function_flag(): Simple Tx can be enabled on Tx queue 1.
ICE_INIT: ice_set_tx_function_flag(): Simple Tx can be enabled on Tx queue 2.
ICE_INIT: ice_set_tx_function_flag(): Simple Tx can be enabled on Tx queue 3.
ICE_INIT: ice_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are satisfied. Rx Burst Bulk Alloc function will be used on port=0, queue=0.
ICE_INIT: ice_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are satisfied. Rx Burst Bulk Alloc function will be used on port=0, queue=1.
ICE_INIT: ice_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are satisfied. Rx Burst Bulk Alloc function will be used on port=0, queue=2.
ICE_INIT: ice_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are satisfied. Rx Burst Bulk Alloc function will be used on port=0, queue=3.
ICE_INIT: ice_tx_queue_start(): >>
ICE_INIT: ice_tx_queue_start(): >>
ICE_INIT: ice_tx_queue_start(): >>
ICE_INIT: ice_tx_queue_start(): >>
ICE_INIT: ice_rx_queue_start(): >>
ICE_DRIVER: ice_program_hw_rx_queue(): Port (0) - Rx queue (0) is set with RXDID : 22
ICE_INIT: ice_rx_queue_start(): >>
ICE_DRIVER: ice_program_hw_rx_queue(): Port (0) - Rx queue (1) is set with RXDID : 22
ICE_INIT: ice_rx_queue_start(): >>
ICE_DRIVER: ice_program_hw_rx_queue(): Port (0) - Rx queue (2) is set with RXDID : 22
ICE_INIT: ice_rx_queue_start(): >>
ICE_DRIVER: ice_program_hw_rx_queue(): Port (0) - Rx queue (3) is set with RXDID : 22
ICE_INIT: ice_set_rx_function(): >>
ICE_DRIVER: ice_set_rx_function(): Using AVX2 OFFLOAD Vector Rx (port 0).
ICE_DRIVER: ice_set_tx_function(): Using avx2 Vector Tx (port 0).
ICE_DRIVER: ice_vsi_del_vlan_zero(): Failed to remove VLAN ID 0
ICE_DRIVER: __vsi_queues_bind_intr(): queue 1 is binding to vect 1
ICE_DRIVER: __vsi_queues_bind_intr(): queue 2 is binding to vect 1
ICE_DRIVER: __vsi_queues_bind_intr(): queue 3 is binding to vect 1
ICE_DRIVER: __vsi_queues_bind_intr(): queue 4 is binding to vect 1
ICE_DRIVER: ice_dev_start(): fail to set vsi broadcast
ICE_DRIVER: ice_promisc_enable(): Promisc mode has already been enabled
Port 0: B4:96:91:D5:B6:C0
Checking link statuses...
Done
testpmd> ICE_DRIVER: ice_interrupt_handler(): OICR: link state change event
Port 0: link state change event
ICE_DRIVER: ice_interrupt_handler(): OICR: link state change event
Port 0: link state change event
testpmd> start
io packet forwarding - ports=1 - cores=1 - streams=4 - NUMA support enabled, MP allocation mode: native
Logical Core 1 (socket 1) forwards packets on 4 streams:
RX P=0/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00
RX P=0/Q=1 (socket 0) -> TX P=0/Q=1 (socket 0) peer=02:00:00:00:00:00
RX P=0/Q=2 (socket 0) -> TX P=0/Q=2 (socket 0) peer=02:00:00:00:00:00
RX P=0/Q=3 (socket 0) -> TX P=0/Q=3 (socket 0) peer=02:00:00:00:00:00
port 0/queue 1: received 2 packets
src=14:23:F2:1C:6E:90 - dst=33:33:00:00:00:16 - pool=mb_pool_0 - type=0x86dd - length=150 - nb_segs=1 - RSS hash=0xa2fda219 - RSS queue=0x1 - hw ptype: L2_ETHER L3_IPV6_EXT_UNKNOWN L4_ICMP - sw ptype: L2_ETHER L3_IPV6_EXT - l2_len=14 - l3_len=48 - Receive queue=0x1
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
src=14:23:F2:1C:6E:90 - dst=33:33:00:00:00:16 - pool=mb_pool_0 - type=0x86dd - length=150 - nb_segs=1 - RSS hash=0xa2fda219 - RSS queue=0x1 - hw ptype: L2_ETHER L3_IPV6_EXT_UNKNOWN L4_ICMP - sw ptype: L2_ETHER L3_IPV6_EXT - l2_len=14 - l3_len=48 - Receive queue=0x1
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
io packet forwarding packets/burst=32
nb forwarding cores=1 - nb forwarding ports=1
port 0: RX queue number: 4 Tx queue number: 4
Rx offloads=0x80001 Tx offloads=0x10000
RX queue: 0
RX desc=1024 - RX free threshold=32
RX threshold registers: pthresh=0 hthresh=0 wthresh=0
RX Offloads=0x0
TX queue: 0
TX desc=1024 - TX free threshold=32
TX threshold registers: pthresh=32 hthresh=0 wthresh=0
TX offloads=0x10000 - TX RS bit threshold=32
ICE_DRIVER: ice_update_vsi_stats(): ************** VSI[6] stats start **************
ICE_DRIVER: ice_update_vsi_stats(): rx_bytes: 900
ICE_DRIVER: ice_update_vsi_stats(): rx_unicast: 0
ICE_DRIVER: ice_update_vsi_stats(): rx_multicast: 6
ICE_DRIVER: ice_update_vsi_stats(): rx_broadcast: 0
ICE_DRIVER: ice_update_vsi_stats(): rx_discards: 2
ICE_DRIVER: ice_update_vsi_stats(): rx_unknown_protocol: 0
ICE_DRIVER: ice_update_vsi_stats(): tx_bytes: 0
ICE_DRIVER: ice_update_vsi_stats(): tx_unicast: 0
ICE_DRIVER: ice_update_vsi_stats(): tx_multicast: 0
ICE_DRIVER: ice_update_vsi_stats(): tx_broadcast: 0
ICE_DRIVER: ice_update_vsi_stats(): tx_discards: 0
ICE_DRIVER: ice_update_vsi_stats(): tx_errors: 0
ICE_DRIVER: ice_update_vsi_stats(): ************** VSI[6] stats end ****************
ICE_DRIVER: ice_stats_get(): *************** PF stats start *****************
ICE_DRIVER: ice_stats_get(): rx_bytes: 900
ICE_DRIVER: ice_stats_get(): rx_unicast: 0
ICE_DRIVER: ice_stats_get(): rx_multicast:6
ICE_DRIVER: ice_stats_get(): rx_broadcast:0
ICE_DRIVER: ice_stats_get(): rx_discards:0
ICE_DRIVER: ice_stats_get(): vsi rx_discards:2
ICE_DRIVER: ice_stats_get(): rx_unknown_protocol: 0
ICE_DRIVER: ice_stats_get(): tx_bytes: 0
ICE_DRIVER: ice_stats_get(): tx_unicast: 0
ICE_DRIVER: ice_stats_get(): tx_multicast:0
ICE_DRIVER: ice_stats_get(): tx_broadcast:0
ICE_DRIVER: ice_stats_get(): tx_discards:0
ICE_DRIVER: ice_stats_get(): vsi tx_discards:0
ICE_DRIVER: ice_stats_get(): tx_errors: 0
ICE_DRIVER: ice_stats_get(): tx_dropped_link_down: 0
ICE_DRIVER: ice_stats_get(): crc_errors: 0
ICE_DRIVER: ice_stats_get(): illegal_bytes: 0
ICE_DRIVER: ice_stats_get(): error_bytes: 0
ICE_DRIVER: ice_stats_get(): mac_local_faults: 2
ICE_DRIVER: ice_stats_get(): mac_remote_faults: 3
ICE_DRIVER: ice_stats_get(): link_xon_rx: 0
ICE_DRIVER: ice_stats_get(): link_xoff_rx: 0
ICE_DRIVER: ice_stats_get(): link_xon_tx: 0
ICE_DRIVER: ice_stats_get(): link_xoff_tx: 0
ICE_DRIVER: ice_stats_get(): rx_size_64: 0
ICE_DRIVER: ice_stats_get(): rx_size_127: 0
ICE_DRIVER: ice_stats_get(): rx_size_255: 6
ICE_DRIVER: ice_stats_get(): rx_size_511: 0
ICE_DRIVER: ice_stats_get(): rx_size_1023: 0
ICE_DRIVER: ice_stats_get(): rx_size_1522: 0
ICE_DRIVER: ice_stats_get(): rx_size_big: 0
ICE_DRIVER: ice_stats_get(): rx_undersize: 0
ICE_DRIVER: ice_stats_get(): rx_fragments: 0
ICE_DRIVER: ice_stats_get(): rx_oversize: 0
ICE_DRIVER: ice_stats_get(): rx_jabber: 0
ICE_DRIVER: ice_stats_get(): tx_size_64: 0
ICE_DRIVER: ice_stats_get(): tx_size_127: 0
ICE_DRIVER: ice_stats_get(): tx_size_255: 0
ICE_DRIVER: ice_stats_get(): tx_size_511: 0
ICE_DRIVER: ice_stats_get(): tx_size_1023: 0
ICE_DRIVER: ice_stats_get(): tx_size_1522: 0
ICE_DRIVER: ice_stats_get(): tx_size_big: 0
ICE_DRIVER: ice_stats_get(): rx_len_errors: 0
ICE_DRIVER: ice_stats_get(): ************* PF stats end ****************
testpmd>
testpmd> port 0/queue 2: received 1 packets
src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 - type=0x0800 - length=142 - nb_segs=1 - RSS hash=0x76d9c29e - RSS queue=0x2 - 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=5398 - Receive queue=0x2
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
port 0/queue 2: sent 1 packets
src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 - type=0x0800 - length=142 - nb_segs=1 - RSS hash=0x76d9c29e - RSS queue=0x2 - 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=5398 - Send queue=0x2
ol_flags: RTE_MBUF_F_TX_L4_NO_CKSUM
testpmd>
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: E810 VLAN offload wrong behavior
2025-07-14 7:48 ` Ernesto Ruffini
@ 2025-07-14 12:49 ` Ivan Malov
2025-07-14 13:50 ` Ernesto Ruffini
0 siblings, 1 reply; 10+ messages in thread
From: Ivan Malov @ 2025-07-14 12:49 UTC (permalink / raw)
To: Ernesto Ruffini; +Cc: users
[-- Attachment #1: Type: text/plain, Size: 3415 bytes --]
Hi Ernesto,
On Mon, 14 Jul 2025, Ernesto Ruffini wrote:
> Hi Ivan,
> Thanks for the hint.
> I ran testpmd with the suggested parameter, but I cannot find where the
> function gets selected.
> I attach the full log here.
Thanks. The message to look for appears closer to the end of start sequence:
> ICE_DRIVER: ice_set_rx_function(): Using AVX2 OFFLOAD Vector Rx (port 0).
But before investigating the code of that Rx function, perhaps it pays to make
sure patch [1] is applied. Everything is so recent that most likely it has not
landed 24.11 release yet. Theoretically, the bug the patch is trying to fix has
something to do with multi-queue and VLAN stripping. See if you can't apply the
patch in 24.11 or rebuild from the current main of dpdk-next-net repository.
Thank you.
[1] https://mails.dpdk.org/archives/dev/2025-June/320530.html
> Thanks
> Ernesto
>
> -----Original Message-----
> From: Ivan Malov <ivan.malov@arknetworks.am>
> Sent: Monday, July 14, 2025 02:04
> To: Ernesto Ruffini <eruffini@outsys.org>
> Cc: users@dpdk.org
> Subject: Re: E810 VLAN offload wrong behavior
>
> Hi Ernesto,
>
> On Fri, 11 Jul 2025, Ernesto Ruffini wrote:
>
>>
>> Hi,
>>
>> We found a strange behavior of the E810 VLAN offload.
>>
>> We are running DPDK 24.11.2 with ice driver 1.15.4, firmware 4.60 and
>> COMMS DDP 1.3.46
>>
>>
>>
>> The NIC receives an IPv4/UDP packet inside VLAN 300.
>>
>> If we run dpdk-testpmd with a single queue, everything seems fine:
>>
>>
>>
>> dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 -- -i
>>
>>
>>
>> set verbose 5
>>
>> port stop 0
>>
>> port config 0 rx_offload vlan_strip on
>>
>> port start 0
>>
>> start
>>
>>
>>
>> And the packet is correctly displayed:
>>
>> src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 -
> type=0x0800 - length=142 - nb_segs=1 - VLAN tci=0x12c - 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=5398 - Receive queue=0x0
>>
>> ol_flags: RTE_MBUF_F_RX_VLAN 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
>>
>>
>>
>> But if we use a different number of queues:
>>
>>
>>
>> dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 -- -i --rxq=4 --txq=4
>
> It would be helpful to enable debug logs with EAL argument
> --log-level='.*',8 so that one can see which 'rx_pkt_burst' method gets
> selected by the driver.
> Then one can inspect the implementation of that particular function to see
> whether offloads are handled correctly.
>
> Thank you.
>
>>
>>
>>
>> The VLAN is in fact removed, but there is no evidence of that:
>>
>>
>>
>> src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 -
>> type=0x0800 - length=142 - nb_segs=1 - RSS hash=0xfae3080 - 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=5398 - 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
>>
>>
>>
>> There was a bug in some previous versions of DPDK about E810 and VLAN
> offload, but it was fixed.
>>
>> Are we doing something wrong or is there a problem with the driver?
>>
>>
>>
>> Thank you
>>
>> Ernesto
>>
>>
>>
>>
>>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: E810 VLAN offload wrong behavior
2025-07-14 12:49 ` Ivan Malov
@ 2025-07-14 13:50 ` Ernesto Ruffini
2025-07-14 16:12 ` Ivan Malov
0 siblings, 1 reply; 10+ messages in thread
From: Ernesto Ruffini @ 2025-07-14 13:50 UTC (permalink / raw)
To: 'Ivan Malov'; +Cc: users
Hi Ivan,
Thank you for your quick answer.
I tried to apply the patch but got a compilation error:
../drivers/net/ice/ice_ethdev.c:5003:71: error: dereferencing pointer to
incomplete type ‘const struct ci_rx_queue’
qrx_context_offset = QRX_CONTEXT(ICE_L2TSEL_QRX_CONTEXT_REG_IDX,
rxq->reg_idx);
So I did "git clone git://dpdk.org/next/dpdk-next-net" and from there it
compiled.
Unfortunately it got consistent, but worse:
The selected rx function is the same:
ICE_DRIVER: ice_set_rx_function(): Using AVX2 OFFLOAD Vector Rx (port 0).
But it now drops the VLAN, without signaling it, in all cases.
With 1 queue:
ol_flags: RTE_MBUF_F_RX_L4_CKSUM_GOOD RTE_MBUF_F_RX_IP_CKSUM_GOOD
RTE_MBUF_F_RX_OUTER_L4_CKSUM_GOOD
With 4 queues:
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
I double checked with plain 24.11.2 and indeed with just one queue it is
still
ol_flags: RTE_MBUF_F_RX_VLAN 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
So I'm confident the lab environment is still good
Thank you
Ernesto
-----Original Message-----
From: Ivan Malov <ivan.malov@arknetworks.am>
Sent: Monday, July 14, 2025 14:49
To: Ernesto Ruffini <eruffini@outsys.org>
Cc: users@dpdk.org
Subject: RE: E810 VLAN offload wrong behavior
Hi Ernesto,
On Mon, 14 Jul 2025, Ernesto Ruffini wrote:
> Hi Ivan,
> Thanks for the hint.
> I ran testpmd with the suggested parameter, but I cannot find where
> the function gets selected.
> I attach the full log here.
Thanks. The message to look for appears closer to the end of start sequence:
> ICE_DRIVER: ice_set_rx_function(): Using AVX2 OFFLOAD Vector Rx (port 0).
But before investigating the code of that Rx function, perhaps it pays to
make sure patch [1] is applied. Everything is so recent that most likely it
has not landed 24.11 release yet. Theoretically, the bug the patch is trying
to fix has something to do with multi-queue and VLAN stripping. See if you
can't apply the patch in 24.11 or rebuild from the current main of
dpdk-next-net repository.
Thank you.
[1] https://mails.dpdk.org/archives/dev/2025-June/320530.html
> Thanks
> Ernesto
>
> -----Original Message-----
> From: Ivan Malov <ivan.malov@arknetworks.am>
> Sent: Monday, July 14, 2025 02:04
> To: Ernesto Ruffini <eruffini@outsys.org>
> Cc: users@dpdk.org
> Subject: Re: E810 VLAN offload wrong behavior
>
> Hi Ernesto,
>
> On Fri, 11 Jul 2025, Ernesto Ruffini wrote:
>
>>
>> Hi,
>>
>> We found a strange behavior of the E810 VLAN offload.
>>
>> We are running DPDK 24.11.2 with ice driver 1.15.4, firmware 4.60 and
>> COMMS DDP 1.3.46
>>
>>
>>
>> The NIC receives an IPv4/UDP packet inside VLAN 300.
>>
>> If we run dpdk-testpmd with a single queue, everything seems fine:
>>
>>
>>
>> dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 -- -i
>>
>>
>>
>> set verbose 5
>>
>> port stop 0
>>
>> port config 0 rx_offload vlan_strip on
>>
>> port start 0
>>
>> start
>>
>>
>>
>> And the packet is correctly displayed:
>>
>> src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 -
> type=0x0800 - length=142 - nb_segs=1 - VLAN tci=0x12c - 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=5398 - Receive queue=0x0
>>
>> ol_flags: RTE_MBUF_F_RX_VLAN 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
>>
>>
>>
>> But if we use a different number of queues:
>>
>>
>>
>> dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 -- -i --rxq=4 --txq=4
>
> It would be helpful to enable debug logs with EAL argument
> --log-level='.*',8 so that one can see which 'rx_pkt_burst' method
> gets selected by the driver.
> Then one can inspect the implementation of that particular function to
> see whether offloads are handled correctly.
>
> Thank you.
>
>>
>>
>>
>> The VLAN is in fact removed, but there is no evidence of that:
>>
>>
>>
>> src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 -
>> type=0x0800 - length=142 - nb_segs=1 - RSS hash=0xfae3080 - 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=5398 - 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
>>
>>
>>
>> There was a bug in some previous versions of DPDK about E810 and VLAN
> offload, but it was fixed.
>>
>> Are we doing something wrong or is there a problem with the driver?
>>
>>
>>
>> Thank you
>>
>> Ernesto
>>
>>
>>
>>
>>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: E810 VLAN offload wrong behavior
2025-07-14 13:50 ` Ernesto Ruffini
@ 2025-07-14 16:12 ` Ivan Malov
2025-07-15 7:30 ` Ernesto Ruffini
0 siblings, 1 reply; 10+ messages in thread
From: Ivan Malov @ 2025-07-14 16:12 UTC (permalink / raw)
To: Ernesto Ruffini; +Cc: users
[-- Attachment #1: Type: text/plain, Size: 5508 bytes --]
Hi Ernesto,
That's interesting. To be honest, I'm not an expert in this driver. So far it
does not seem the issue is with the specific Rx function, yet may be it pays to
temporarily change "#ifdef RTE_ARCH_X86" to "#if 0" on line [1] in the original
source of 24.11.2 and rebuild? Just to make sure the Rx method is a don't care.
Thank you.
[1] https://github.com/DPDK/dpdk/blob/4c5634de9f933555bab9c64a533d3dca999071cd/drivers/net/ice/ice_rxtx.c#L3489
On Mon, 14 Jul 2025, Ernesto Ruffini wrote:
> Hi Ivan,
> Thank you for your quick answer.
> I tried to apply the patch but got a compilation error:
>
> ../drivers/net/ice/ice_ethdev.c:5003:71: error: dereferencing pointer to
> incomplete type ‘const struct ci_rx_queue’
> qrx_context_offset = QRX_CONTEXT(ICE_L2TSEL_QRX_CONTEXT_REG_IDX,
> rxq->reg_idx);
>
> So I did "git clone git://dpdk.org/next/dpdk-next-net" and from there it
> compiled.
> Unfortunately it got consistent, but worse:
> The selected rx function is the same:
> ICE_DRIVER: ice_set_rx_function(): Using AVX2 OFFLOAD Vector Rx (port 0).
> But it now drops the VLAN, without signaling it, in all cases.
> With 1 queue:
> ol_flags: RTE_MBUF_F_RX_L4_CKSUM_GOOD RTE_MBUF_F_RX_IP_CKSUM_GOOD
> RTE_MBUF_F_RX_OUTER_L4_CKSUM_GOOD
> With 4 queues:
> 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
>
> I double checked with plain 24.11.2 and indeed with just one queue it is
> still
> ol_flags: RTE_MBUF_F_RX_VLAN 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
>
> So I'm confident the lab environment is still good
>
> Thank you
> Ernesto
>
>
> -----Original Message-----
> From: Ivan Malov <ivan.malov@arknetworks.am>
> Sent: Monday, July 14, 2025 14:49
> To: Ernesto Ruffini <eruffini@outsys.org>
> Cc: users@dpdk.org
> Subject: RE: E810 VLAN offload wrong behavior
>
> Hi Ernesto,
>
> On Mon, 14 Jul 2025, Ernesto Ruffini wrote:
>
>> Hi Ivan,
>> Thanks for the hint.
>> I ran testpmd with the suggested parameter, but I cannot find where
>> the function gets selected.
>> I attach the full log here.
>
> Thanks. The message to look for appears closer to the end of start sequence:
>> ICE_DRIVER: ice_set_rx_function(): Using AVX2 OFFLOAD Vector Rx (port 0).
>
> But before investigating the code of that Rx function, perhaps it pays to
> make sure patch [1] is applied. Everything is so recent that most likely it
> has not landed 24.11 release yet. Theoretically, the bug the patch is trying
> to fix has something to do with multi-queue and VLAN stripping. See if you
> can't apply the patch in 24.11 or rebuild from the current main of
> dpdk-next-net repository.
>
> Thank you.
>
> [1] https://mails.dpdk.org/archives/dev/2025-June/320530.html
>
>> Thanks
>> Ernesto
>>
>> -----Original Message-----
>> From: Ivan Malov <ivan.malov@arknetworks.am>
>> Sent: Monday, July 14, 2025 02:04
>> To: Ernesto Ruffini <eruffini@outsys.org>
>> Cc: users@dpdk.org
>> Subject: Re: E810 VLAN offload wrong behavior
>>
>> Hi Ernesto,
>>
>> On Fri, 11 Jul 2025, Ernesto Ruffini wrote:
>>
>>>
>>> Hi,
>>>
>>> We found a strange behavior of the E810 VLAN offload.
>>>
>>> We are running DPDK 24.11.2 with ice driver 1.15.4, firmware 4.60 and
>>> COMMS DDP 1.3.46
>>>
>>>
>>>
>>> The NIC receives an IPv4/UDP packet inside VLAN 300.
>>>
>>> If we run dpdk-testpmd with a single queue, everything seems fine:
>>>
>>>
>>>
>>> dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 -- -i
>>>
>>>
>>>
>>> set verbose 5
>>>
>>> port stop 0
>>>
>>> port config 0 rx_offload vlan_strip on
>>>
>>> port start 0
>>>
>>> start
>>>
>>>
>>>
>>> And the packet is correctly displayed:
>>>
>>> src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 -
>> type=0x0800 - length=142 - nb_segs=1 - VLAN tci=0x12c - 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=5398 - Receive queue=0x0
>>>
>>> ol_flags: RTE_MBUF_F_RX_VLAN 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
>>>
>>>
>>>
>>> But if we use a different number of queues:
>>>
>>>
>>>
>>> dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 -- -i --rxq=4 --txq=4
>>
>> It would be helpful to enable debug logs with EAL argument
>> --log-level='.*',8 so that one can see which 'rx_pkt_burst' method
>> gets selected by the driver.
>> Then one can inspect the implementation of that particular function to
>> see whether offloads are handled correctly.
>>
>> Thank you.
>>
>>>
>>>
>>>
>>> The VLAN is in fact removed, but there is no evidence of that:
>>>
>>>
>>>
>>> src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 -
>>> type=0x0800 - length=142 - nb_segs=1 - RSS hash=0xfae3080 - 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=5398 - 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
>>>
>>>
>>>
>>> There was a bug in some previous versions of DPDK about E810 and VLAN
>> offload, but it was fixed.
>>>
>>> Are we doing something wrong or is there a problem with the driver?
>>>
>>>
>>>
>>> Thank you
>>>
>>> Ernesto
>>>
>>>
>>>
>>>
>>>
>>
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: E810 VLAN offload wrong behavior
2025-07-14 16:12 ` Ivan Malov
@ 2025-07-15 7:30 ` Ernesto Ruffini
2025-07-15 8:20 ` Ivan Malov
2025-07-15 8:31 ` Ivan Malov
0 siblings, 2 replies; 10+ messages in thread
From: Ernesto Ruffini @ 2025-07-15 7:30 UTC (permalink / raw)
To: 'Ivan Malov'; +Cc: users
Hi Ivan,
It worked!
ICE_INIT: ice_set_rx_function(): Rx Burst Bulk Alloc Preconditions are
satisfied. Rx Burst Bulk Alloc function will be used on port 0.
And all the flags are there, with both one and four queues.
Any idea on where to report this as a bug in the AVX2 OFFLOAD Vector Rx
driver function, as apparently it is?
Thank you
Ernesto
-----Original Message-----
From: Ivan Malov <ivan.malov@arknetworks.am>
Sent: Monday, July 14, 2025 18:12
To: Ernesto Ruffini <eruffini@outsys.org>
Cc: users@dpdk.org
Subject: RE: E810 VLAN offload wrong behavior
Hi Ernesto,
That's interesting. To be honest, I'm not an expert in this driver. So far
it does not seem the issue is with the specific Rx function, yet may be it
pays to temporarily change "#ifdef RTE_ARCH_X86" to "#if 0" on line [1] in
the original source of 24.11.2 and rebuild? Just to make sure the Rx method
is a don't care.
Thank you.
[1]
https://github.com/DPDK/dpdk/blob/4c5634de9f933555bab9c64a533d3dca999071cd/d
rivers/net/ice/ice_rxtx.c#L3489
On Mon, 14 Jul 2025, Ernesto Ruffini wrote:
> Hi Ivan,
> Thank you for your quick answer.
> I tried to apply the patch but got a compilation error:
>
> ../drivers/net/ice/ice_ethdev.c:5003:71: error: dereferencing pointer
> to incomplete type ?const struct ci_rx_queue?
> qrx_context_offset = QRX_CONTEXT(ICE_L2TSEL_QRX_CONTEXT_REG_IDX,
> rxq->reg_idx);
>
> So I did "git clone git://dpdk.org/next/dpdk-next-net" and from there
> it compiled.
> Unfortunately it got consistent, but worse:
> The selected rx function is the same:
> ICE_DRIVER: ice_set_rx_function(): Using AVX2 OFFLOAD Vector Rx (port 0).
> But it now drops the VLAN, without signaling it, in all cases.
> With 1 queue:
> ol_flags: RTE_MBUF_F_RX_L4_CKSUM_GOOD RTE_MBUF_F_RX_IP_CKSUM_GOOD
> RTE_MBUF_F_RX_OUTER_L4_CKSUM_GOOD With 4 queues:
> 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
>
> I double checked with plain 24.11.2 and indeed with just one queue it
> is still
> ol_flags: RTE_MBUF_F_RX_VLAN 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
>
> So I'm confident the lab environment is still good
>
> Thank you
> Ernesto
>
>
> -----Original Message-----
> From: Ivan Malov <ivan.malov@arknetworks.am>
> Sent: Monday, July 14, 2025 14:49
> To: Ernesto Ruffini <eruffini@outsys.org>
> Cc: users@dpdk.org
> Subject: RE: E810 VLAN offload wrong behavior
>
> Hi Ernesto,
>
> On Mon, 14 Jul 2025, Ernesto Ruffini wrote:
>
>> Hi Ivan,
>> Thanks for the hint.
>> I ran testpmd with the suggested parameter, but I cannot find where
>> the function gets selected.
>> I attach the full log here.
>
> Thanks. The message to look for appears closer to the end of start
sequence:
>> ICE_DRIVER: ice_set_rx_function(): Using AVX2 OFFLOAD Vector Rx (port 0).
>
> But before investigating the code of that Rx function, perhaps it pays
> to make sure patch [1] is applied. Everything is so recent that most
> likely it has not landed 24.11 release yet. Theoretically, the bug the
> patch is trying to fix has something to do with multi-queue and VLAN
> stripping. See if you can't apply the patch in 24.11 or rebuild from
> the current main of dpdk-next-net repository.
>
> Thank you.
>
> [1] https://mails.dpdk.org/archives/dev/2025-June/320530.html
>
>> Thanks
>> Ernesto
>>
>> -----Original Message-----
>> From: Ivan Malov <ivan.malov@arknetworks.am>
>> Sent: Monday, July 14, 2025 02:04
>> To: Ernesto Ruffini <eruffini@outsys.org>
>> Cc: users@dpdk.org
>> Subject: Re: E810 VLAN offload wrong behavior
>>
>> Hi Ernesto,
>>
>> On Fri, 11 Jul 2025, Ernesto Ruffini wrote:
>>
>>>
>>> Hi,
>>>
>>> We found a strange behavior of the E810 VLAN offload.
>>>
>>> We are running DPDK 24.11.2 with ice driver 1.15.4, firmware 4.60
>>> and COMMS DDP 1.3.46
>>>
>>>
>>>
>>> The NIC receives an IPv4/UDP packet inside VLAN 300.
>>>
>>> If we run dpdk-testpmd with a single queue, everything seems fine:
>>>
>>>
>>>
>>> dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 -- -i
>>>
>>>
>>>
>>> set verbose 5
>>>
>>> port stop 0
>>>
>>> port config 0 rx_offload vlan_strip on
>>>
>>> port start 0
>>>
>>> start
>>>
>>>
>>>
>>> And the packet is correctly displayed:
>>>
>>> src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 -
>> type=0x0800 - length=142 - nb_segs=1 - VLAN tci=0x12c - 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=5398 - Receive queue=0x0
>>>
>>> ol_flags: RTE_MBUF_F_RX_VLAN 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
>>>
>>>
>>>
>>> But if we use a different number of queues:
>>>
>>>
>>>
>>> dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 -- -i --rxq=4 --txq=4
>>
>> It would be helpful to enable debug logs with EAL argument
>> --log-level='.*',8 so that one can see which 'rx_pkt_burst' method
>> gets selected by the driver.
>> Then one can inspect the implementation of that particular function
>> to see whether offloads are handled correctly.
>>
>> Thank you.
>>
>>>
>>>
>>>
>>> The VLAN is in fact removed, but there is no evidence of that:
>>>
>>>
>>>
>>> src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 -
>>> type=0x0800 - length=142 - nb_segs=1 - RSS hash=0xfae3080 - 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=5398 - 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
>>>
>>>
>>>
>>> There was a bug in some previous versions of DPDK about E810 and
>>> VLAN
>> offload, but it was fixed.
>>>
>>> Are we doing something wrong or is there a problem with the driver?
>>>
>>>
>>>
>>> Thank you
>>>
>>> Ernesto
>>>
>>>
>>>
>>>
>>>
>>
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: E810 VLAN offload wrong behavior
2025-07-15 7:30 ` Ernesto Ruffini
@ 2025-07-15 8:20 ` Ivan Malov
2025-07-15 8:31 ` Ivan Malov
1 sibling, 0 replies; 10+ messages in thread
From: Ivan Malov @ 2025-07-15 8:20 UTC (permalink / raw)
To: Ernesto Ruffini; +Cc: users
[-- Attachment #1: Type: text/plain, Size: 7083 bytes --]
Hi Ernesto,
Good that you've managed to make a difference. However, this is hardly an ideal
solution performance-wise, as the plain Rx function does not utilise vector
extensions. It is peculiar that the AVX2 version shows this strange behaviour.
For the bug report, one may want to use https://bugs.dpdk.org/ -> 'New'.
Apart from that, there is a very recent fix [1] that is supposed to be applied
on top of the current main branch of 'dpdk-next-net'. May be it is worth trying
without the "if 0" Rx function workaround, just to confirm that indeed the issue
has something to do with the Rx function and not with device register settings.
Thank you.
[1] https://patches.dpdk.org/project/dpdk/list/?series=35700
On Tue, 15 Jul 2025, Ernesto Ruffini wrote:
> Hi Ivan,
> It worked!
>
> ICE_INIT: ice_set_rx_function(): Rx Burst Bulk Alloc Preconditions are
> satisfied. Rx Burst Bulk Alloc function will be used on port 0.
>
> And all the flags are there, with both one and four queues.
>
> Any idea on where to report this as a bug in the AVX2 OFFLOAD Vector Rx
> driver function, as apparently it is?
>
> Thank you
> Ernesto
>
>
> -----Original Message-----
> From: Ivan Malov <ivan.malov@arknetworks.am>
> Sent: Monday, July 14, 2025 18:12
> To: Ernesto Ruffini <eruffini@outsys.org>
> Cc: users@dpdk.org
> Subject: RE: E810 VLAN offload wrong behavior
>
> Hi Ernesto,
>
> That's interesting. To be honest, I'm not an expert in this driver. So far
> it does not seem the issue is with the specific Rx function, yet may be it
> pays to temporarily change "#ifdef RTE_ARCH_X86" to "#if 0" on line [1] in
> the original source of 24.11.2 and rebuild? Just to make sure the Rx method
> is a don't care.
>
> Thank you.
>
> [1]
> https://github.com/DPDK/dpdk/blob/4c5634de9f933555bab9c64a533d3dca999071cd/d
> rivers/net/ice/ice_rxtx.c#L3489
>
> On Mon, 14 Jul 2025, Ernesto Ruffini wrote:
>
>> Hi Ivan,
>> Thank you for your quick answer.
>> I tried to apply the patch but got a compilation error:
>>
>> ../drivers/net/ice/ice_ethdev.c:5003:71: error: dereferencing pointer
>> to incomplete type ?const struct ci_rx_queue?
>> qrx_context_offset = QRX_CONTEXT(ICE_L2TSEL_QRX_CONTEXT_REG_IDX,
>> rxq->reg_idx);
>>
>> So I did "git clone git://dpdk.org/next/dpdk-next-net" and from there
>> it compiled.
>> Unfortunately it got consistent, but worse:
>> The selected rx function is the same:
>> ICE_DRIVER: ice_set_rx_function(): Using AVX2 OFFLOAD Vector Rx (port 0).
>> But it now drops the VLAN, without signaling it, in all cases.
>> With 1 queue:
>> ol_flags: RTE_MBUF_F_RX_L4_CKSUM_GOOD RTE_MBUF_F_RX_IP_CKSUM_GOOD
>> RTE_MBUF_F_RX_OUTER_L4_CKSUM_GOOD With 4 queues:
>> 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
>>
>> I double checked with plain 24.11.2 and indeed with just one queue it
>> is still
>> ol_flags: RTE_MBUF_F_RX_VLAN 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
>>
>> So I'm confident the lab environment is still good
>>
>> Thank you
>> Ernesto
>>
>>
>> -----Original Message-----
>> From: Ivan Malov <ivan.malov@arknetworks.am>
>> Sent: Monday, July 14, 2025 14:49
>> To: Ernesto Ruffini <eruffini@outsys.org>
>> Cc: users@dpdk.org
>> Subject: RE: E810 VLAN offload wrong behavior
>>
>> Hi Ernesto,
>>
>> On Mon, 14 Jul 2025, Ernesto Ruffini wrote:
>>
>>> Hi Ivan,
>>> Thanks for the hint.
>>> I ran testpmd with the suggested parameter, but I cannot find where
>>> the function gets selected.
>>> I attach the full log here.
>>
>> Thanks. The message to look for appears closer to the end of start
> sequence:
>>> ICE_DRIVER: ice_set_rx_function(): Using AVX2 OFFLOAD Vector Rx (port 0).
>>
>> But before investigating the code of that Rx function, perhaps it pays
>> to make sure patch [1] is applied. Everything is so recent that most
>> likely it has not landed 24.11 release yet. Theoretically, the bug the
>> patch is trying to fix has something to do with multi-queue and VLAN
>> stripping. See if you can't apply the patch in 24.11 or rebuild from
>> the current main of dpdk-next-net repository.
>>
>> Thank you.
>>
>> [1] https://mails.dpdk.org/archives/dev/2025-June/320530.html
>>
>>> Thanks
>>> Ernesto
>>>
>>> -----Original Message-----
>>> From: Ivan Malov <ivan.malov@arknetworks.am>
>>> Sent: Monday, July 14, 2025 02:04
>>> To: Ernesto Ruffini <eruffini@outsys.org>
>>> Cc: users@dpdk.org
>>> Subject: Re: E810 VLAN offload wrong behavior
>>>
>>> Hi Ernesto,
>>>
>>> On Fri, 11 Jul 2025, Ernesto Ruffini wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> We found a strange behavior of the E810 VLAN offload.
>>>>
>>>> We are running DPDK 24.11.2 with ice driver 1.15.4, firmware 4.60
>>>> and COMMS DDP 1.3.46
>>>>
>>>>
>>>>
>>>> The NIC receives an IPv4/UDP packet inside VLAN 300.
>>>>
>>>> If we run dpdk-testpmd with a single queue, everything seems fine:
>>>>
>>>>
>>>>
>>>> dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 -- -i
>>>>
>>>>
>>>>
>>>> set verbose 5
>>>>
>>>> port stop 0
>>>>
>>>> port config 0 rx_offload vlan_strip on
>>>>
>>>> port start 0
>>>>
>>>> start
>>>>
>>>>
>>>>
>>>> And the packet is correctly displayed:
>>>>
>>>> src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 -
>>> type=0x0800 - length=142 - nb_segs=1 - VLAN tci=0x12c - 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=5398 - Receive queue=0x0
>>>>
>>>> ol_flags: RTE_MBUF_F_RX_VLAN 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
>>>>
>>>>
>>>>
>>>> But if we use a different number of queues:
>>>>
>>>>
>>>>
>>>> dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 -- -i --rxq=4 --txq=4
>>>
>>> It would be helpful to enable debug logs with EAL argument
>>> --log-level='.*',8 so that one can see which 'rx_pkt_burst' method
>>> gets selected by the driver.
>>> Then one can inspect the implementation of that particular function
>>> to see whether offloads are handled correctly.
>>>
>>> Thank you.
>>>
>>>>
>>>>
>>>>
>>>> The VLAN is in fact removed, but there is no evidence of that:
>>>>
>>>>
>>>>
>>>> src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 -
>>>> type=0x0800 - length=142 - nb_segs=1 - RSS hash=0xfae3080 - 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=5398 - 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
>>>>
>>>>
>>>>
>>>> There was a bug in some previous versions of DPDK about E810 and
>>>> VLAN
>>> offload, but it was fixed.
>>>>
>>>> Are we doing something wrong or is there a problem with the driver?
>>>>
>>>>
>>>>
>>>> Thank you
>>>>
>>>> Ernesto
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: E810 VLAN offload wrong behavior
2025-07-15 7:30 ` Ernesto Ruffini
2025-07-15 8:20 ` Ivan Malov
@ 2025-07-15 8:31 ` Ivan Malov
2025-07-15 9:17 ` Ernesto Ruffini
1 sibling, 1 reply; 10+ messages in thread
From: Ivan Malov @ 2025-07-15 8:31 UTC (permalink / raw)
To: Ernesto Ruffini; +Cc: users
[-- Attachment #1: Type: text/plain, Size: 6527 bytes --]
Sorry, the bug might already exist. See [1]. So may be you can add your
findings as a comment there.
Thank you.
[1] https://bugs.dpdk.org/show_bug.cgi?id=1677
On Tue, 15 Jul 2025, Ernesto Ruffini wrote:
> Hi Ivan,
> It worked!
>
> ICE_INIT: ice_set_rx_function(): Rx Burst Bulk Alloc Preconditions are
> satisfied. Rx Burst Bulk Alloc function will be used on port 0.
>
> And all the flags are there, with both one and four queues.
>
> Any idea on where to report this as a bug in the AVX2 OFFLOAD Vector Rx
> driver function, as apparently it is?
>
> Thank you
> Ernesto
>
>
> -----Original Message-----
> From: Ivan Malov <ivan.malov@arknetworks.am>
> Sent: Monday, July 14, 2025 18:12
> To: Ernesto Ruffini <eruffini@outsys.org>
> Cc: users@dpdk.org
> Subject: RE: E810 VLAN offload wrong behavior
>
> Hi Ernesto,
>
> That's interesting. To be honest, I'm not an expert in this driver. So far
> it does not seem the issue is with the specific Rx function, yet may be it
> pays to temporarily change "#ifdef RTE_ARCH_X86" to "#if 0" on line [1] in
> the original source of 24.11.2 and rebuild? Just to make sure the Rx method
> is a don't care.
>
> Thank you.
>
> [1]
> https://github.com/DPDK/dpdk/blob/4c5634de9f933555bab9c64a533d3dca999071cd/d
> rivers/net/ice/ice_rxtx.c#L3489
>
> On Mon, 14 Jul 2025, Ernesto Ruffini wrote:
>
>> Hi Ivan,
>> Thank you for your quick answer.
>> I tried to apply the patch but got a compilation error:
>>
>> ../drivers/net/ice/ice_ethdev.c:5003:71: error: dereferencing pointer
>> to incomplete type ?const struct ci_rx_queue?
>> qrx_context_offset = QRX_CONTEXT(ICE_L2TSEL_QRX_CONTEXT_REG_IDX,
>> rxq->reg_idx);
>>
>> So I did "git clone git://dpdk.org/next/dpdk-next-net" and from there
>> it compiled.
>> Unfortunately it got consistent, but worse:
>> The selected rx function is the same:
>> ICE_DRIVER: ice_set_rx_function(): Using AVX2 OFFLOAD Vector Rx (port 0).
>> But it now drops the VLAN, without signaling it, in all cases.
>> With 1 queue:
>> ol_flags: RTE_MBUF_F_RX_L4_CKSUM_GOOD RTE_MBUF_F_RX_IP_CKSUM_GOOD
>> RTE_MBUF_F_RX_OUTER_L4_CKSUM_GOOD With 4 queues:
>> 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
>>
>> I double checked with plain 24.11.2 and indeed with just one queue it
>> is still
>> ol_flags: RTE_MBUF_F_RX_VLAN 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
>>
>> So I'm confident the lab environment is still good
>>
>> Thank you
>> Ernesto
>>
>>
>> -----Original Message-----
>> From: Ivan Malov <ivan.malov@arknetworks.am>
>> Sent: Monday, July 14, 2025 14:49
>> To: Ernesto Ruffini <eruffini@outsys.org>
>> Cc: users@dpdk.org
>> Subject: RE: E810 VLAN offload wrong behavior
>>
>> Hi Ernesto,
>>
>> On Mon, 14 Jul 2025, Ernesto Ruffini wrote:
>>
>>> Hi Ivan,
>>> Thanks for the hint.
>>> I ran testpmd with the suggested parameter, but I cannot find where
>>> the function gets selected.
>>> I attach the full log here.
>>
>> Thanks. The message to look for appears closer to the end of start
> sequence:
>>> ICE_DRIVER: ice_set_rx_function(): Using AVX2 OFFLOAD Vector Rx (port 0).
>>
>> But before investigating the code of that Rx function, perhaps it pays
>> to make sure patch [1] is applied. Everything is so recent that most
>> likely it has not landed 24.11 release yet. Theoretically, the bug the
>> patch is trying to fix has something to do with multi-queue and VLAN
>> stripping. See if you can't apply the patch in 24.11 or rebuild from
>> the current main of dpdk-next-net repository.
>>
>> Thank you.
>>
>> [1] https://mails.dpdk.org/archives/dev/2025-June/320530.html
>>
>>> Thanks
>>> Ernesto
>>>
>>> -----Original Message-----
>>> From: Ivan Malov <ivan.malov@arknetworks.am>
>>> Sent: Monday, July 14, 2025 02:04
>>> To: Ernesto Ruffini <eruffini@outsys.org>
>>> Cc: users@dpdk.org
>>> Subject: Re: E810 VLAN offload wrong behavior
>>>
>>> Hi Ernesto,
>>>
>>> On Fri, 11 Jul 2025, Ernesto Ruffini wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> We found a strange behavior of the E810 VLAN offload.
>>>>
>>>> We are running DPDK 24.11.2 with ice driver 1.15.4, firmware 4.60
>>>> and COMMS DDP 1.3.46
>>>>
>>>>
>>>>
>>>> The NIC receives an IPv4/UDP packet inside VLAN 300.
>>>>
>>>> If we run dpdk-testpmd with a single queue, everything seems fine:
>>>>
>>>>
>>>>
>>>> dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 -- -i
>>>>
>>>>
>>>>
>>>> set verbose 5
>>>>
>>>> port stop 0
>>>>
>>>> port config 0 rx_offload vlan_strip on
>>>>
>>>> port start 0
>>>>
>>>> start
>>>>
>>>>
>>>>
>>>> And the packet is correctly displayed:
>>>>
>>>> src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 -
>>> type=0x0800 - length=142 - nb_segs=1 - VLAN tci=0x12c - 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=5398 - Receive queue=0x0
>>>>
>>>> ol_flags: RTE_MBUF_F_RX_VLAN 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
>>>>
>>>>
>>>>
>>>> But if we use a different number of queues:
>>>>
>>>>
>>>>
>>>> dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 -- -i --rxq=4 --txq=4
>>>
>>> It would be helpful to enable debug logs with EAL argument
>>> --log-level='.*',8 so that one can see which 'rx_pkt_burst' method
>>> gets selected by the driver.
>>> Then one can inspect the implementation of that particular function
>>> to see whether offloads are handled correctly.
>>>
>>> Thank you.
>>>
>>>>
>>>>
>>>>
>>>> The VLAN is in fact removed, but there is no evidence of that:
>>>>
>>>>
>>>>
>>>> src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 -
>>>> type=0x0800 - length=142 - nb_segs=1 - RSS hash=0xfae3080 - 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=5398 - 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
>>>>
>>>>
>>>>
>>>> There was a bug in some previous versions of DPDK about E810 and
>>>> VLAN
>>> offload, but it was fixed.
>>>>
>>>> Are we doing something wrong or is there a problem with the driver?
>>>>
>>>>
>>>>
>>>> Thank you
>>>>
>>>> Ernesto
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: E810 VLAN offload wrong behavior
2025-07-15 8:31 ` Ivan Malov
@ 2025-07-15 9:17 ` Ernesto Ruffini
0 siblings, 0 replies; 10+ messages in thread
From: Ernesto Ruffini @ 2025-07-15 9:17 UTC (permalink / raw)
To: 'Ivan Malov'; +Cc: users
Hi Ivan,
Yesterday's fix you mentioned in your previous message worked very well.
Hope it will be included in the next 24.11.3 version.
Thank you very much
Ernesto
-----Original Message-----
From: Ivan Malov <ivan.malov@arknetworks.am>
Sent: Tuesday, July 15, 2025 10:32
To: Ernesto Ruffini <eruffini@outsys.org>
Cc: users@dpdk.org
Subject: RE: E810 VLAN offload wrong behavior
Sorry, the bug might already exist. See [1]. So may be you can add your
findings as a comment there.
Thank you.
[1] https://bugs.dpdk.org/show_bug.cgi?id=1677
On Tue, 15 Jul 2025, Ernesto Ruffini wrote:
> Hi Ivan,
> It worked!
>
> ICE_INIT: ice_set_rx_function(): Rx Burst Bulk Alloc Preconditions are
> satisfied. Rx Burst Bulk Alloc function will be used on port 0.
>
> And all the flags are there, with both one and four queues.
>
> Any idea on where to report this as a bug in the AVX2 OFFLOAD Vector
> Rx driver function, as apparently it is?
>
> Thank you
> Ernesto
>
>
> -----Original Message-----
> From: Ivan Malov <ivan.malov@arknetworks.am>
> Sent: Monday, July 14, 2025 18:12
> To: Ernesto Ruffini <eruffini@outsys.org>
> Cc: users@dpdk.org
> Subject: RE: E810 VLAN offload wrong behavior
>
> Hi Ernesto,
>
> That's interesting. To be honest, I'm not an expert in this driver. So
> far it does not seem the issue is with the specific Rx function, yet
> may be it pays to temporarily change "#ifdef RTE_ARCH_X86" to "#if 0"
> on line [1] in the original source of 24.11.2 and rebuild? Just to
> make sure the Rx method is a don't care.
>
> Thank you.
>
> [1]
> https://github.com/DPDK/dpdk/blob/4c5634de9f933555bab9c64a533d3dca9990
> 71cd/d
> rivers/net/ice/ice_rxtx.c#L3489
>
> On Mon, 14 Jul 2025, Ernesto Ruffini wrote:
>
>> Hi Ivan,
>> Thank you for your quick answer.
>> I tried to apply the patch but got a compilation error:
>>
>> ../drivers/net/ice/ice_ethdev.c:5003:71: error: dereferencing pointer
>> to incomplete type ?const struct ci_rx_queue?
>> qrx_context_offset = QRX_CONTEXT(ICE_L2TSEL_QRX_CONTEXT_REG_IDX,
>> rxq->reg_idx);
>>
>> So I did "git clone git://dpdk.org/next/dpdk-next-net" and from there
>> it compiled.
>> Unfortunately it got consistent, but worse:
>> The selected rx function is the same:
>> ICE_DRIVER: ice_set_rx_function(): Using AVX2 OFFLOAD Vector Rx (port 0).
>> But it now drops the VLAN, without signaling it, in all cases.
>> With 1 queue:
>> ol_flags: RTE_MBUF_F_RX_L4_CKSUM_GOOD RTE_MBUF_F_RX_IP_CKSUM_GOOD
>> RTE_MBUF_F_RX_OUTER_L4_CKSUM_GOOD With 4 queues:
>> 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
>>
>> I double checked with plain 24.11.2 and indeed with just one queue it
>> is still
>> ol_flags: RTE_MBUF_F_RX_VLAN 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
>>
>> So I'm confident the lab environment is still good
>>
>> Thank you
>> Ernesto
>>
>>
>> -----Original Message-----
>> From: Ivan Malov <ivan.malov@arknetworks.am>
>> Sent: Monday, July 14, 2025 14:49
>> To: Ernesto Ruffini <eruffini@outsys.org>
>> Cc: users@dpdk.org
>> Subject: RE: E810 VLAN offload wrong behavior
>>
>> Hi Ernesto,
>>
>> On Mon, 14 Jul 2025, Ernesto Ruffini wrote:
>>
>>> Hi Ivan,
>>> Thanks for the hint.
>>> I ran testpmd with the suggested parameter, but I cannot find where
>>> the function gets selected.
>>> I attach the full log here.
>>
>> Thanks. The message to look for appears closer to the end of start
> sequence:
>>> ICE_DRIVER: ice_set_rx_function(): Using AVX2 OFFLOAD Vector Rx (port
0).
>>
>> But before investigating the code of that Rx function, perhaps it
>> pays to make sure patch [1] is applied. Everything is so recent that
>> most likely it has not landed 24.11 release yet. Theoretically, the
>> bug the patch is trying to fix has something to do with multi-queue
>> and VLAN stripping. See if you can't apply the patch in 24.11 or
>> rebuild from the current main of dpdk-next-net repository.
>>
>> Thank you.
>>
>> [1] https://mails.dpdk.org/archives/dev/2025-June/320530.html
>>
>>> Thanks
>>> Ernesto
>>>
>>> -----Original Message-----
>>> From: Ivan Malov <ivan.malov@arknetworks.am>
>>> Sent: Monday, July 14, 2025 02:04
>>> To: Ernesto Ruffini <eruffini@outsys.org>
>>> Cc: users@dpdk.org
>>> Subject: Re: E810 VLAN offload wrong behavior
>>>
>>> Hi Ernesto,
>>>
>>> On Fri, 11 Jul 2025, Ernesto Ruffini wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> We found a strange behavior of the E810 VLAN offload.
>>>>
>>>> We are running DPDK 24.11.2 with ice driver 1.15.4, firmware 4.60
>>>> and COMMS DDP 1.3.46
>>>>
>>>>
>>>>
>>>> The NIC receives an IPv4/UDP packet inside VLAN 300.
>>>>
>>>> If we run dpdk-testpmd with a single queue, everything seems fine:
>>>>
>>>>
>>>>
>>>> dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 -- -i
>>>>
>>>>
>>>>
>>>> set verbose 5
>>>>
>>>> port stop 0
>>>>
>>>> port config 0 rx_offload vlan_strip on
>>>>
>>>> port start 0
>>>>
>>>> start
>>>>
>>>>
>>>>
>>>> And the packet is correctly displayed:
>>>>
>>>> src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 -
>>> type=0x0800 - length=142 - nb_segs=1 - VLAN tci=0x12c - 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=5398 - Receive queue=0x0
>>>>
>>>> ol_flags: RTE_MBUF_F_RX_VLAN 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
>>>>
>>>>
>>>>
>>>> But if we use a different number of queues:
>>>>
>>>>
>>>>
>>>> dpdk-testpmd -a 0000:4b:00.0 -c ffffff -n 8 -- -i --rxq=4 --txq=4
>>>
>>> It would be helpful to enable debug logs with EAL argument
>>> --log-level='.*',8 so that one can see which 'rx_pkt_burst' method
>>> gets selected by the driver.
>>> Then one can inspect the implementation of that particular function
>>> to see whether offloads are handled correctly.
>>>
>>> Thank you.
>>>
>>>>
>>>>
>>>>
>>>> The VLAN is in fact removed, but there is no evidence of that:
>>>>
>>>>
>>>>
>>>> src=08:02:03:04:05:06 - dst=00:1A:CA:01:00:96 - pool=mb_pool_0 -
>>>> type=0x0800 - length=142 - nb_segs=1 - RSS hash=0xfae3080 - 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=5398 - 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
>>>>
>>>>
>>>>
>>>> There was a bug in some previous versions of DPDK about E810 and
>>>> VLAN
>>> offload, but it was fixed.
>>>>
>>>> Are we doing something wrong or is there a problem with the driver?
>>>>
>>>>
>>>>
>>>> Thank you
>>>>
>>>> Ernesto
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2025-07-15 9:19 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-07-11 11:28 E810 VLAN offload wrong behavior Ernesto Ruffini
2025-07-14 0:03 ` Ivan Malov
2025-07-14 7:48 ` Ernesto Ruffini
2025-07-14 12:49 ` Ivan Malov
2025-07-14 13:50 ` Ernesto Ruffini
2025-07-14 16:12 ` Ivan Malov
2025-07-15 7:30 ` Ernesto Ruffini
2025-07-15 8:20 ` Ivan Malov
2025-07-15 8:31 ` Ivan Malov
2025-07-15 9:17 ` Ernesto Ruffini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).