Bruce, Agreed. I think that lines up with the follow-on patch in this series.
The first patch only adds the common base private-size mechanism. The second patch applies it for the PMD path so the PMD-owned mbuf pool creation cases account for the required private data size consistently. I plan to ask the PMD owner to review/follow up on that second patch, since that is where the platform/driver-specific pool sizing policy belongs. The intent is still to preserve existing per-pool private data, while adding the common base reservation needed by the shared metadata accessors. Regards, -rt From: Bruce Richardson <[email protected]> Date: Tuesday, September 1, 2026 at 8:21 AM To: Randy Tice (rtice) <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [RFC] mbuf: add configurable base private size for pktmbuf pools On Mon, Aug 31, 2026 at 06:20:19PM +0000, Randy Tice (rtice) 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. > My 2c. Rather than having a fixed build-time, or a configurable runtime set private mbuf data size, I think the main thing to be fixed here is to ensure that all cases where mbuf pools are created, the private data size is configurable in those cases. /Bruce > 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. > > The proposed generic model is to add a configurable base private size > for pktmbuf pools. The effective private size would be: > > align(pool_requested_priv_size + application_base_priv_size, > RTE_MBUF_PRIV_ALIGN) > > The tentative EAL option name is: > > --mbuf-base-priv-size=<size> > > The intent is: > * default behavior remains unchanged when the option is not used; > * the configured base size is added to the private size requested by > each pktmbuf pool; > * the final effective private size remains aligned to > RTE_MBUF_PRIV_ALIGN; > * pool-specific private-data requests still work as they do today; > * DPDK centralizes the policy so pools created outside application > control can reserve the same base private-data space as > application-created pools. > > This is not intended to define ownership or layout of the private area. > It only ensures that a deployment can reserve a common base amount of > private data consistently. Applications, drivers, libraries, or > components would still be responsible for their own interpretation of > the reserved private area. > > Questions for the list: > 1. Is a deployment-wide pktmbuf base private-size reservation > something DPDK would consider acceptable? > 2. Is --mbuf-base-priv-size=<size> a reasonable name, or would another > name better describe the intent? > 3. Should DPDK expose the effective-size calculation as a helper so > pool-creation paths outside application control can apply the same > rule? > 4. Would maintainers prefer consumer updates in the same series as > example users, or as follow-up patches after the generic mbuf/EAL > change is accepted? > 5. Would maintainers prefer this to remain component-specific, even if > more than one driver, library, or pool-creation path may need to > apply the same base reservation? > > The main goal is to avoid downstream mbuf layout changes and avoid > component-specific configuration drift, while still allowing > deployments to reserve a consistent private-data area across all packet > mbuf pools, including pools created outside direct application control. > > Thanks, > Randy
