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.
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
