From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Stephen Hemminger" <stephen@networkplumber.org>
Cc: <dev@dpdk.org>
Subject: RE: [RFC PATCH v11] pile stack and mempool driver
Date: Tue, 11 Aug 2026 21:16:48 +0200 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35F659D4@smartserver.smartshare.dk> (raw)
In-Reply-To: <20260811082528.0d71179d@phoenix.local>
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Tuesday, 11 August 2026 17.25
>
> On Tue, 11 Aug 2026 12:35:41 +0000
> Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > Early submission of:
> > - A new "pile" stack-like implementation using the Stack API, and
> > - an accompanying "pile" mempool driver.
> >
> > For CI test and community feedback.
> >
> > Needless to say, this must be separated into multiple independent
> > series of patches.
> > And release notes must be added.
> > For now, I'm submitting a snapshot of work in progress.
> >
> > The "pile" somewhat resembles the lock-free stack, but operates on
> > bulks (arrays) of objects, to significantly reduce linked list
> > traversal.
> > With the pile's default bulk size of 32 objects, a mempool cache
> > flush/refill traverses a linked list of only 16 elements, whereas
> > the lock-free stack would traverse a linked list of 512 elements.
> >
> > Some performance numbers from mempool_perf_autotest_2cores, all
> > with cache=1024 cores=2 n_keep=32768:
> >
> > start performance test (using ring_mp_mc, with cache)
> > n_get_bulk= 64 n_put_bulk= 64 constant_n=0 rate_persec= 753985338
> > n_get_bulk=256 n_put_bulk=256 constant_n=0 rate_persec= 755805913
> >
> > start performance test for lf_stack (with cache)
> > n_get_bulk= 64 n_put_bulk= 64 constant_n=0 rate_persec= 29132352
> > n_get_bulk=256 n_put_bulk=256 constant_n=0 rate_persec= 29276708
> >
> > start performance test for pile (with cache)
> > n_get_bulk= 64 n_put_bulk= 64 constant_n=0 rate_persec= 560159479
> > n_get_bulk=256 n_put_bulk=256 constant_n=0 rate_persec= 557910933
> >
> > Hat tip to Bruce for bringing attention to the ring not being the
> > optimal mempool driver!
> >
> > Note: The GitHub "mini" tests don't include the "pile" mempool
> driver,
> > and are expected to fail.
> >
> > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
>
> Right but the 32 bit code fails at run time.
>
> MEMPOOL: Cache size 250 not divisible by 32, rounding down to 224.
> STACK: rte_stack_create(): Pile is not supported on your platform
The "pile" and "lf_stack" stack types (and mempool drivers) rely on a 128-bit CAS instruction, which is only available on x86_64 and arm64, so asking for one of those mempool drivers will fail on 32-bit architectures.
>
> Should be possible to correct this at compile. Like if pile is not
> available on this platform, something else should be the default.
Yep. The default will remain the "ring" mempool driver.
I only temporarily selected the "pile" driver as the default to ensure that it got properly tested by the CI.
>
> The CI failures indicate places where it is likely to be a problem
> for users.
Other CI failures are related to "mini" builds.
The "mini" builds only include the "ring" mempool driver, so selecting the "pile" mempool driver naturally fails:
MEMPOOL: Unknown mempool_ops <pile>, of 6 ops registered
I think v11 has brought sufficient CI/AI feedback to split it into individual patch series for the "pile" stack/driver and the mempool optimizations.
Will proceed with that now.
Thank you for the advanced AI reviews, Stephen; they were helpful.
-Morten
prev parent reply other threads:[~2026-08-11 19:16 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-01 7:15 [RFC PATCH] NEW: pile stack and mempool driver Morten Brørup
2026-08-01 10:09 ` [RFC PATCH v2] " Morten Brørup
2026-08-01 10:17 ` [RFC PATCH v3] " Morten Brørup
2026-08-01 11:13 ` [RFC PATCH v4] " Morten Brørup
2026-08-02 7:24 ` [RFC PATCH v5] " Morten Brørup
2026-08-02 9:59 ` [RFC PATCH v6] " Morten Brørup
2026-08-02 15:22 ` Stephen Hemminger
2026-08-02 16:45 ` Morten Brørup
2026-08-03 8:14 ` [RFC PATCH v7] " Morten Brørup
2026-08-03 23:02 ` Stephen Hemminger
2026-08-10 9:02 ` [RFC PATCH v8] " Morten Brørup
2026-08-10 13:58 ` [RFC PATCH v9] " Morten Brørup
2026-08-10 15:12 ` [RFC PATCH v10] " Morten Brørup
2026-08-10 16:15 ` Stephen Hemminger
2026-08-10 18:36 ` Morten Brørup
2026-08-11 12:35 ` [RFC PATCH v11] " Morten Brørup
2026-08-11 15:25 ` Stephen Hemminger
2026-08-11 19:16 ` Morten Brørup [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=98CBD80474FA8B44BF855DF32C47DC35F659D4@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=dev@dpdk.org \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox