<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Bruce,</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Agreed. I think that lines up with the follow-on patch in this series.</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
The first patch only adds the common base private-size mechanism. The second</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
patch applies it for the PMD path so the PMD-owned mbuf pool creation cases</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
account for the required private data size consistently.</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I plan to ask the PMD owner to review/follow up on that second patch, since</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
that is where the platform/driver-specific pool sizing policy belongs.</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
The intent is still to preserve existing per-pool private data, while adding</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
the common base reservation needed by the shared metadata accessors.</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Regards,</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
-rt</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="mail-editor-reference-message-container">
<div style="padding: 3pt 0in 0in; border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) currentcolor currentcolor;">
<div style="text-align: left; font-family: Aptos; font-size: 12pt; color: black;">
<b>From: </b>Bruce Richardson <bruce.richardson@intel.com><br>
<b>Date: </b>Tuesday, September 1, 2026 at 8:21 AM<br>
<b>To: </b>Randy Tice (rtice) <rtice@cisco.com><br>
<b>Cc: </b>dev@dpdk.org <dev@dpdk.org><br>
<b>Subject: </b>Re: [RFC] mbuf: add configurable base private size for pktmbuf pools<br>
<br>
</div>
</div>
<div id="mail-editor-reference-message-body">
<div class="ms-outlook-mobile-reference-message skipProofing">
<meta name="Generator" content="Microsoft Exchange Server">
</div>
<div class="PlainText" style="font-size: 11pt;">On Mon, Aug 31, 2026 at 06:20:19PM +0000, Randy Tice (rtice) wrote:<br>
> Hi,<br>
><br>
> I would like to get feedback on a proposed mbuf change before sending<br>
> patches.<br>
><br>
> Some deployments need a guaranteed private-data reservation in every<br>
> packet mbuf, across multiple mbuf pools and across different consumers<br>
> of the mbuf APIs.<br>
><br>
> Today, each pktmbuf pool can request a private size when the pool is<br>
> created. That works when the application owns all pool creation policy<br>
> directly. However, not all relevant mbuf pools are necessarily created<br>
> by application code. Some pools may be created by libraries, drivers,<br>
> or other components outside direct application control.<br>
><br>
> One example already in DPDK is vhost crypto, which creates its own mbuf<br>
> pool and supplies a private size for struct vhost_crypto_data_req.<br>
> There are also driver-created pktmbuf-style pools, such as cnxk inline<br>
> meta pools and TAP GSO context pools. These are examples of<br>
> pool-creation paths where the application may not directly control the<br>
> private-size value used at creation time.<br>
><br>
<br>
My 2c.<br>
<br>
Rather than having a fixed build-time, or a configurable runtime set<br>
private mbuf data size, I think the main thing to be fixed here is to<br>
ensure that all cases where mbuf pools are created, the private data size<br>
is configurable in those cases.<br>
<br>
/Bruce<br>
<br>
> A PMD-specific devarg could solve one instance of this problem, such as<br>
> a single driver-created pool, but that seems too narrow if the<br>
> requirement is not inherently PMD-specific. A deployment with multiple<br>
> drivers, libraries, or other pool-creation paths outside application<br>
> control could need the same base private-size adjustment. In that case,<br>
> configuring the same value independently through component-specific<br>
> options would be fragile and easy to get wrong.<br>
><br>
> The proposed generic model is to add a configurable base private size<br>
> for pktmbuf pools. The effective private size would be:<br>
><br>
> align(pool_requested_priv_size + application_base_priv_size,<br>
> RTE_MBUF_PRIV_ALIGN)<br>
><br>
> The tentative EAL option name is:<br>
><br>
> --mbuf-base-priv-size=<size><br>
><br>
> The intent is:<br>
> * default behavior remains unchanged when the option is not used;<br>
> * the configured base size is added to the private size requested by<br>
> each pktmbuf pool;<br>
> * the final effective private size remains aligned to<br>
> RTE_MBUF_PRIV_ALIGN;<br>
> * pool-specific private-data requests still work as they do today;<br>
> * DPDK centralizes the policy so pools created outside application<br>
> control can reserve the same base private-data space as<br>
> application-created pools.<br>
><br>
> This is not intended to define ownership or layout of the private area.<br>
> It only ensures that a deployment can reserve a common base amount of<br>
> private data consistently. Applications, drivers, libraries, or<br>
> components would still be responsible for their own interpretation of<br>
> the reserved private area.<br>
><br>
> Questions for the list:<br>
> 1. Is a deployment-wide pktmbuf base private-size reservation<br>
> something DPDK would consider acceptable?<br>
> 2. Is --mbuf-base-priv-size=<size> a reasonable name, or would another<br>
> name better describe the intent?<br>
> 3. Should DPDK expose the effective-size calculation as a helper so<br>
> pool-creation paths outside application control can apply the same<br>
> rule?<br>
> 4. Would maintainers prefer consumer updates in the same series as<br>
> example users, or as follow-up patches after the generic mbuf/EAL<br>
> change is accepted?<br>
> 5. Would maintainers prefer this to remain component-specific, even if<br>
> more than one driver, library, or pool-creation path may need to<br>
> apply the same base reservation?<br>
><br>
> The main goal is to avoid downstream mbuf layout changes and avoid<br>
> component-specific configuration drift, while still allowing<br>
> deployments to reserve a consistent private-data area across all packet<br>
> mbuf pools, including pools created outside direct application control.<br>
><br>
> Thanks,<br>
> Randy<br>
</div>
</div>
</div>
</body>
</html>