> On Wed, Aug 12, 2026 at 01:47:56PM +0000, Morten Brørup wrote:
> > Added a new high-performance lock-free "pile", using the Stack API.
> > The pile behaves roughly like a stack, but is not strictly LIFO.
> >
> > The pile is optimized for pushing/popping bulks of objects, which
> > it does significantly faster than the lock-free stack.
> >
> > Pushing/popping a number of objects not divisible by the compile time
> > configurable bulk size is handled gracefully, but not as fast as
> > complete bulks.
> >
> > Performance examples, stack_pile_perf_autotest vs. stack_lf_autotest:
> >
> > On a single core, pushing/popping 1 or 8 objects is similar speed.
> > On a single core, pushing/popping 32 objects is 2x faster.
> > On a single core, pushing/popping 512 objects is 10x faster.
> >
> > On four cores, pushing/popping 1, 8 or 32 objects is slightly faster.
> > On four cores, pushing/popping 512 objects is 4x faster.
> >
> > Signed-off-by: Morten Brørup <[email protected]>
> > ---
> > app/test/test_stack.c | 71 +++++-
> > app/test/test_stack_perf.c | 15 +-
> > config/rte_config.h | 3 +
> > doc/guides/prog_guide/stack_lib.rst | 67 +++++-
> > lib/mempool/rte_mempool.h | 2 +-
> > lib/stack/meson.build | 3 +-
> > lib/stack/rte_stack.c | 18 +-
> > lib/stack/rte_stack.h | 79 +++++++
> > lib/stack/rte_stack_lf.h | 1 +
> > lib/stack/rte_stack_pile.c | 35 +++
> > lib/stack/rte_stack_pile.h | 334 ++++++++++++++++++++++++++++
> > 11 files changed, 609 insertions(+), 19 deletions(-)
> > create mode 100644 lib/stack/rte_stack_pile.c
> > create mode 100644 lib/stack/rte_stack_pile.h
> >
> Looking at this a little closer, and thinking some more, here are some of
> my further thoughts/ideas on this:
>
> * For most cases using a mempool, I can't see having non-strict LIFO
> behaviour being an issue, and there is nothing in the mempool API that
> makes any ordering guarantees about what buffers get given by get/put,
> and in fact we can't make any guarantees because of the fact of multiple
> cores doing allocs and frees. Therefore, for the mempool driver, I
> believe one pre-emptible implementation is enough, so therefore the pile
> mempool driver should just replace the current LF one.
> * For apps which may want to use the stack structs directly, not through a
> mempool, I can see that having defined ordering behaviour may be
> beneficial. However, if multiple cores are involved, then we can never
> guarantee ordering, I believe, so I'm not sure its worth trying to
> enforce strict LIFO for such cases. [If you need the same elements back
> in the correct order from a core, then use a regular stack without sharing
> it].
> * IF we decide that we really, really want LIFO ordering across multiple
> cores - despite the likely random ordering of allocs/frees between those
> cores, I still think that this implementation should replace the LF
> stack. If we reverse the order of elements on enqueue (or dequeue) then
> we should be closer to correct LIFO ordering - and fully lifo if allocs
> and frees are based on multiples of the burst size.
>
> I suppose for me the main question to be resolved is - do we have scenarios
> where we a) have multi-core operation on the stacks and b) absolutely must
> have strict LIFO ordering? In the absense of that, I'd very much be in
> favour of replacing the existing LF implementation completely with this
> one.
I am agree with Bruce - it is probably worth to replace current lfstack
implementation with this new one,
as new one is proved to be way much faster.
One more observation: instead of making RTE_STACK_PILE_BULK_SIZE compile time
constant,
why not to make it configurable variable (at lfstack instance creation time)?
Then in theory we can support current behavior too - user can create a pile
with no bulks,
and all requests will go via solo code-path.
That way we'll have good perf improvement, while preserving old-behavior
compatibility for those
who needs it.
Though have to admit, I don't know any off-hand who will need it :)
