RE: [RFC PATCH v3 2/2] mempool: de-inline get/put unlikely code paths

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

> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Monday, 16 February 2026 18.36
> 
> On Mon, 16 Feb 2026 15:23:20 +0000
> Morten Brørup <mb@smartsharesystems.com> wrote:
> 
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * @internal
> > + * Put several objects back in the mempool, more than the cache has
> room for; used internally.
> > + *
> > + * @param mp
> > + *   A pointer to the mempool structure.
> > + * @param obj_table
> > + *   A pointer to a table of void * pointers (objects).
> > + * @param n
> > + *   The number of objects to store back in the mempool, must be
> strictly
> > + *   positive.
> > + * @param cache
> > + *   A pointer to a mempool cache structure.
> > + */
> > +__rte_experimental
> > +void
> > +_rte_mempool_do_generic_put_more(struct rte_mempool *mp, void *
> const *obj_table,
> > +		unsigned int n, struct rte_mempool_cache *cache);
> > +
> 
> Don't you want internal not experimental on this.
> You don't want or expect direct callers.

I initially had it internal, but it's being called from an inline function, so it needs to be publicly accessible from applications.
It seems experimental doesn't suffice either - if only stable APIs are allowed - so it probably needs to be a regular API.
We'll get that sorted.

The core question of the RFC is the tradeoff of making he unlikely code path non-inline to gain a smaller footprint of the likely code path.