All of lore.kernel.org
 help / color / mirror / Atom feed
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.