rte_eth_rx_burst -> returning same mbuff pointer twice consecutively

[Chidananda22]

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 .

[yipingwang]

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.

[Chidananda22]

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

[yipingwang]

1. 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

2. 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

3. Enable mempool debug

      CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=y

Helps detect:

• double allocation
• cache corruption
• same buffer returned twice from mempool

4. 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

5. 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

[Chidananda22]

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

[yipingwang]

Those fslmc / dpaa2 portal affined thread logs strongly indicate portal (QBMan SWP) is being re-attached to a different thread/core, which can break ownership model → leading to mbuf reuse / duplication symptoms.