[PATCH v3 1/1] mbuf: add optional no-copy dynamic field storage

[Konstantin Ananyev]

29.09.2026 13:44, Morten Brørup пишет:
>> From: Konstantin Ananyev [mailto:konstantin.v.ananyev at yandex.ru]
>> Sent: Tuesday, 29 September 2026 14.00
>>
>> 28.09.2026 19:16, Randy L Tice пишет:
>>> From: Randy L Tice <rtice at cisco.com>
>>> Date: Thu, 03 Sep 2026 09:13:28 -0400
>>>
>>> Add build-time support for optional cache-line-aligned dynamic-field
>>> storage at the end of struct rte_mbuf.
>>>
>>> The mbuf_dynfield3_size Meson option sets RTE_MBUF_DYNFIELD3_SIZE in
>>> rte_build_config.h. A non-zero value enables the extra area and grows
>>> every mbuf by the configured amount.
>> I am strongly opposed to that patch.
>> Inside mbuf we already do have priv_size that allows user to store
>> his/her specific
>> data straight after rte_mbuf in adjacent manner.
>> It worked well so far for many use-cases (including VPP) and I don't
>> see any
>> reason why this is not enough.
>>   From other side - making size of core rte_mbuf configurable at run-
>> time,
>> will affect DPDK ABI stability in a negative way.
>> Fro my perspective it is much plausible in terms of ABI stability and
>> predictability
>> to have just one fixed layout for the mbuf.
>> Konstantin
> The private data area (priv_size) is independent per mbuf pool, and selected at run-time when creating each pool. As Randy explained in the RFC, this is unavailable for mbuf pools created by other components.

I think it should be trivial to enforce minimal priv_size across all 
mbuf pools what will be obeyed by different components
(as long as they do use rte_pktmbuf_pool_create() and friends):
1) introduce new EAL parameter 'mbuf-min-priv-size' or so (keep default 
as zero)
2) make rte_pktmbuf_pool_create_by_ops() and 
rte_pktmbuf_pool_create_extbuf() to check that input paramter 
'priv_size' GE then value specified by EAL parameter, if so then return 
an error.

>
> Mbuf dynamic fields are shared across all mbuf pools, and serves the need with an existing API. So I am strongly in favor of using the mbuf dynamic fields API for this.
>
> I agree with Konstantin that it would be optimal if the size of the added dynfields area was run-time configurable (as an EAL startup parameter).
> However, such a modification to the mbuf library would also require that the performance cost in the dataplane is negligible. We don't want to compromise on mbuf performance for applications not using this new feature.
>
> Randy,
> Could you please explore such an approach?
>
> -Morten