topic Re: rte_eth_rx_burst -> returning same mbuff pointer twice consecutively in Layerscape

rte_eth_rx_burst -> returning same mbuff pointer twice consecutively

Chidananda22 — Wed, 10 Jun 2026 09:00:27 GMT

From my application calling rte_eth_rx_burst

checking sometimes same mbuff coming twice . Checked code buffer not freeing . With out mbuff free what could be the scenario that same mbuff pointer received twice .

Re: rte_eth_rx_burst -> returning same mbuff pointer twice consecutively

yipingwang — Wed, 10 Jun 2026 09:16:26 GMT

Without an explicit mbuf free in your code, the most likely scenarios are that the mbuf is still being effectively returned/reused through another path in the application or shared unsafely across threads/cores, or that a special driver/path-specific buffer handling issue is corrupting lifecycle state.

Cross-core/shared mbuf ownership issue. One documented case used one CPU for RX and many worker CPUs consuming mbufs from a ring; the mbuf address was then seen reused/overwritten while still referenced elsewhere. NXP specifically asked whether RTE_MBUF_REFCNT_ATOMIC was enabled for multicore access, and the customer said yes, but the issue was still treated as application-level ownership/lifetime handling.,
Duplicate release or hidden return path in the application pipeline. NXP’s guidance in that case was to instrument buffer allocate/release/packet-send actions to see whether the same address was being released back to the buffer pool more than once.
PMD/driver returning malformed mbufs to pool in special paths. There is a separate DPAA2 PMD case involving chained mbufs where mbufs returned to the mempool appeared corrupted ( next not cleared), causing sanity-check failures on later allocation. That is not the same symptom as your report, but it does show that special buffer handling paths can lead to later reuse/corruption symptoms.
Same source and destination mbuf in crypto path. In a DPAA security/IPsec case, NXP noted that if sym->m_dst is NULL , then m_src and m_dst use the same mbuf. That can make packet contents appear rewritten “in place” under load, even though the pointer identity did not change.

Re: rte_eth_rx_burst -> returning same mbuff pointer twice consecutively

Chidananda22 — Wed, 10 Jun 2026 10:16:43 GMT

thanks @yipingwang for your quick reply and suggestions. from code i am not to figure out more . Any DPDK debug flag can help ?

Re: rte_eth_rx_burst -> returning same mbuff pointer twice consecutively

yipingwang — Thu, 11 Jun 2026 02:25:14 GMT

Enable DPDK log levels (first thing to try)

Run your app with:

--log-level=8

What you’ll see:

RX descriptor handling
buffer allocation/recycling
PMD behavior

Enable mbuf debug checking (very useful)

Rebuild DPDK with:

CONFIG_RTE_LIBRTE_MBUF_DEBUG=y

This will:

Validate mbuf consistency
Catch:
- corrupted metadata
- reused mbuf incorrectly
- invalid refcnt

Enable mempool debug

CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=y

Helps detect:

double allocation
cache corruption
same buffer returned twice from mempool

Poison/free tracking (EXTREMELY useful)

You can enable memory overwrite checking:

CONFIG_RTE_MALLOC_DEBUG=y

and

--mp-alloc=debug

This helps detect:

overwrite before/after mbuf
hidden memory corruption

Quick isolation trick (VERY effective)

Run

testpmd -- -i

Then:

set fwd rxonly

start

If duplication disappears:

your application bug

If still happens:

PMD / HW / queue config issue

Re: rte_eth_rx_burst -> returning same mbuff pointer twice consecutively

Chidananda22 — Thu, 11 Jun 2026 11:38:54 GMT

Thanks @yipingwang for Quick reply . I will try and update you .

One observation every time multiple mbuf ( same address coming ) getting below prints in screen

fslmc: dpaa2_get_qbman_swp(): New Portal 0x17ffd61c0 (5) affined thread - 1953
fslmc: dpaa2_configure_stashing(): Portal= 5 CPU= 10 SDEST= 5
fslmc: DPAA Portal=0x17ffd61c0 (5) is affined to thread 1953