Multiprocess App Problems with tx_burst
Dmitry Kozlyuk
dmitry.kozliuk at gmail.com
Mon Jan 6 21:10:38 CET 2025
2025-01-06 11:05 (UTC-0500), Alan Beadle:
> There is definitely something going wrong with the mbuf allocator.
> Each run results in such different errors that it is difficult to add
> instrumentation for a specific one, but one frequent error is that a
> newly allocated mbuf already has a refcnt of 2, and contains data that
> I am still using elsewhere.
> At each call to rte_pktmbuf_alloc() (with locks around it)
> I immediately do a rte_mbuf_refcnt_read() and ensure
> that it is 1. Sometimes it is 2. This should never occur and I believe
> it proves that DPDK is not working as expected here for some reason.
I suspect that mbufs in use are put into mempool somehow.
Which functions do you use to free mbufs to the pool
on processing paths that do not end with `rte_eth_tx_burst()`?
You can build DPDK with `-Dc_args='-DRTE_LIBRTE_MBUF_DEBUG'`
to enable debug checks in the library.
Unless `RTE_MEMPOOL_F_SC_GET` is used, `rte_pktmbuf_alloc()` is thread-safe.
More information about the users
mailing list