From: bugzilla@dpdk.org
To: dev@dpdk.org
Subject: [wishes/any Bug 2059] Resizable mbuf pool
Date: Thu, 15 Oct 2026 12:56:55 +0000 [thread overview]
Message-ID: <bug-2059-3@https.bugs.dpdk.org/> (raw)
https://bugs.dpdk.org/show_bug.cgi?id=2059
Bug ID: 2059
Summary: Resizable mbuf pool
Product: wishes
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: any
Assignee: dev@dpdk.org
Reporter: mb@smartsharesystems.com
Target Milestone: ---
Typically, the number of mbufs needed in a system scales with multiple
parameters, some are per-interface, and some are system wide.
If a system's number of interfaces is not known at system startup time, it is a
common design pattern to allocate one mbuf pool per interface at runtime, when
each interface is created.
Having one mbuf pool per interface means that the size of each pool needs to be
big enough to serve not only the per-interface mbuf consumption, but also
system-wide mbuf consumption.
This is not memory efficient.
It would be memory efficient to share one (or one per CPU socket) big mbuf pool
across all interfaces (or groups of interfaces attached to each CPU socket), so
the number of mbufs needed for system wide purposes only is allocated once, and
not once per interface.
For this alternative design pattern, where one mbuf pool is shared by all
interfaces, and more interfaces can still be added at runtime, it "must" be
possible to add more mbufs to the mbuf pool at runtime, effectively increasing
its size.
NB:
The ability to reduce the mbuf pool size at runtime too, e.g. when an interface
is deleted, is considered "nice to have" in this context.
--
You are receiving this mail because:
You are the assignee for the bug.
reply other threads:[~2026-10-15 12:56 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=bug-2059-3@https.bugs.dpdk.org/ \
--to=bugzilla@dpdk.org \
--cc=dev@dpdk.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