[PATCH v7 3/7] mbuf: record mbuf operations history
Thomas Monjalon
thomas at monjalon.net
Fri Oct 17 11:09:19 CEST 2025
17/10/2025 09:55, Morten Brørup:
> > From: Thomas Monjalon [mailto:thomas at 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.
Yes but it can happen :)
Anyway there is also the transient of mbuf marked by PMD or app
before being marked by the lib.
I think in those cases it is expected to consider the mbuf
as non-allocated in the stats.
> > > 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.
Yes let's play with it, we may discover that the markers should be changed more deeply.
More information about the dev
mailing list