From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Stephen Hemminger" <stephen@networkplumber.org>,
"Bruce Richardson" <bruce.richardson@intel.com>
Cc: "Kishore Padmanabha" <kishore.padmanabha@broadcom.com>,
"fengchengwen" <fengchengwen@huawei.com>,
"Thomas Monjalon" <thomas@monjalon.net>, "dev" <dev@dpdk.org>,
"Wisam Jaddo" <wisamm@nvidia.com>,
"Andrew Rybchenko" <andrew.rybchenko@oktetlabs.ru>
Subject: RE: mempool cache change
Date: Tue, 21 Jul 2026 11:18:17 +0200 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35F65986@smartserver.smartshare.dk> (raw)
In-Reply-To: <CAOaVG17Ay+b1Hio90Mgq0jrYwFegxOmQ-+2ezXF_cSrk1Zi90g@mail.gmail.com>
From: Stephen Hemminger [mailto:stephen@networkplumber.org]
Sent: Tuesday, 21 July 2026 08.35
>I can't help thinking that there needs to be a more dynamic heuristic.
>Keep existing upper limit but only cache as much as gets used.
>
>There are two main usage models.
>One is fast direct recycling which run to completion generates. The other is when pipeline is used and arrival and departure is on different cores.
In the "different cores" usage model, only half the cache size is active on each thread.
In the "free/put only" thread, only the upper half is active (since we flush to size/2).
In the "alloc/get only" thread, only the lower half is active (since we replenish to size/2).
So, doubling the configured cache size will perform the same as an optimal algorithm.
But it will waste size/2 objects per "free/put only" thread as dead in the per-thread mempool cache's lower half.
Runtime heuristic would introduce a performance cost for checking usage model.
prev parent reply other threads:[~2026-07-21 9:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 16:48 mempool cache change Kishore Padmanabha
2026-07-14 20:08 ` Morten Brørup
2026-07-15 8:11 ` fengchengwen
2026-07-15 9:02 ` Morten Brørup
2026-07-15 15:12 ` Kishore Padmanabha
2026-07-16 9:56 ` Bruce Richardson
2026-07-17 17:10 ` Kishore Padmanabha
2026-07-18 14:07 ` Morten Brørup
2026-07-20 8:12 ` Bruce Richardson
2026-07-20 10:54 ` Morten Brørup
2026-07-21 1:42 ` Kishore Padmanabha
2026-07-21 6:34 ` Stephen Hemminger
2026-07-21 9:02 ` Morten Brørup
2026-07-21 9:11 ` Bruce Richardson
2026-07-21 9:18 ` 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=98CBD80474FA8B44BF855DF32C47DC35F65986@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=kishore.padmanabha@broadcom.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
--cc=wisamm@nvidia.com \
/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