> > 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.
Why? As long as rte_pktmbuf_pool_create() is used by all consumers, it seems
be straightforward to enforce extra room.
If we do need such option, my preference would be to have run-time
configurable.
