> From: Thomas Monjalon [mailto:[email protected]] > Sent: Friday, 17 October 2025 09.32 > > 17/10/2025 00:29, Morten Brørup: > > > + /* Calculate total allocated mbufs */ > > > + uint64_t total_allocated = 0; > > > + for (enum rte_mbuf_history_op op = RTE_MBUF_HISTORY_OP_LIB_ALLOC; > > > + op < RTE_MBUF_HISTORY_OP_MAX; op++) > > > + total_allocated += stats[op]; > > > > I might be overly cautious here, but the app (or driver) might have a > bug, and mark the mbuf with OP_APP_FREE (or OP_PMD_FREE) without > actually freeing the mbuf back to the mempool. > > Yes > > > So you should only trust the mempool library (OP_LIB_FREE) to mark > the mbuf as actually freed. I.e. start the loop at op = > RTE_MBUF_HISTORY_OP_LIB_FREE. > > We cannot because these statistics are about the latest state. > So if the app marks the mbuf as freed after the library, > they should be reported as non allocated.
The app cannot mark the mbuf after calling rte_mbuf_raw_free_bulk(). That would be a "use after free" bug. > > > The app/driver should eventually call rte_mbuf_raw_free_bulk() or > similar to release the mbuf back to the mempool. > > Because we don't know in which order the mbufs are marked > in the call stack, we must trust these free ops. > > I really think there is room for improvements in the details of the > marks > and their usage. I suggest we merge and play with this experimental > feature, > and discuss in the next cycle how to improve the markers. > Since it's only a minor detail in the dump function that I'm having minor doubts about, merging as-is is OK with me. It's more important getting the feature included than making it perfect at its introduction - as you mention yourself: it's an experimental feature.
