On Mon, 31 Aug 2026 18:20:19 +0000 "Randy Tice (rtice)" <[email protected]> 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. > > 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.
