From: Stephen Hemminger <stephen@networkplumber.org>
To: "Randy Tice (rtice)" <rtice@cisco.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [RFC] mbuf: add configurable base private size for pktmbuf pools
Date: Mon, 31 Aug 2026 19:55:16 -0700 [thread overview]
Message-ID: <20260831195516.71a00639@phoenix.local> (raw)
In-Reply-To: <PH0PR11MB76163DCD87BB40C437CB54C8A9A92@PH0PR11MB7616.namprd11.prod.outlook.com>
On Mon, 31 Aug 2026 18:20:19 +0000
"Randy Tice (rtice)" <rtice@cisco.com> wrote:
> Hi,
>
> I would like to get feedback on a proposed mbuf change before sending patches.
>
> Some deployments need a guaranteed private-data reservation in every packet mbuf, across multiple mbuf pools and across different consumers of the mbuf APIs.
>
> Today, each pktmbuf pool can request a private size when the pool is created. That works when the application owns all pool creation policy directly. However, not all relevant mbuf pools are necessarily created by application code. Some pools may be created by libraries, drivers, or other components outside direct application control.
>
> One example already in DPDK is vhost crypto, which creates its own mbuf pool and supplies a private size for struct vhost_crypto_data_req. There are also driver-created pktmbuf-style pools, such as cnxk inline meta pools and TAP GSO context pools. These are examples of pool-creation paths where the application may not directly control the private-size value used at creation time.
>
> A PMD-specific devarg could solve one instance of this problem, such as a single driver-created pool, but that seems too narrow if the requirement is not inherently PMD-specific. A deployment with multiple drivers, libraries, or other pool-creation paths outside application control could need the same base private-size adjustment. In that case, configuring the same value independently through component-specific options would be fragile and easy to get wrong.
Would be better to make it a config compile time option.
Then drivers could use static_assert() to check for space.
Doing it at runtime is harder to handle and enforce.
next prev parent reply other threads:[~2026-09-01 2:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 18:20 [RFC] mbuf: add configurable base private size for pktmbuf pools Randy Tice (rtice)
2026-09-01 2:55 ` Stephen Hemminger [this message]
2026-09-01 7:31 ` Konstantin Ananyev
2026-09-01 11:11 ` Morten Brørup
2026-09-01 15:43 ` Randy Tice (rtice)
2026-09-01 16:22 ` Morten Brørup
2026-09-01 16:36 ` Morten Brørup
2026-09-01 17:01 ` Randy Tice (rtice)
2026-09-01 17:09 ` Konstantin Ananyev
2026-09-01 20:00 ` Randy Tice (rtice)
2026-09-01 12:21 ` Bruce Richardson
2026-09-01 16:03 ` Randy Tice (rtice)
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=20260831195516.71a00639@phoenix.local \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=rtice@cisco.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