[RFC] mbuf: add configurable base private size for pktmbuf pools

[Randy Tice (rtice)]

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 <bruce.richardson at intel.com>
Date: Tuesday, September 1, 2026 at 8:21 AM
To: Randy Tice (rtice) <rtice at cisco.com>
Cc: dev at dpdk.org <dev at dpdk.org>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/dev/attachments/20260901/80edc642/attachment-0001.htm>