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.
