RE: [PATCH v7 3/7] mbuf: record mbuf operations history

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> 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.