Hi Randy.
Hi all,
Thanks for the discussion. We are now where I had hoped we’d get to
during
RFC but we are here.
Konstantin, I understand your concern about making sizeof(struct
rte_mbuf)
depend on a build-time option. That can create different mbuf
layouts between
DPDK builds that otherwise present the same ABI/version, which is
not a good
property for a core public structure.
After thinking through this again, I think the current patch may be
trying too
hard to make this a dynamic-field allocator feature. The actual
requirement is
simpler: a fixed global per-mbuf metadata area that is present in every
pktmbuf object, separate from ordinary application private data, and not
copied by mbuf copy/clone helpers.
The mbuf structure change would look roughly like this:
struct rte_mbuf {
...
uint32_t dynfield1[9]; /**< Reserved for dynamic fields. */
+
+ alignas(RTE_CACHE_LINE_SIZE)
+ uint8_t metadata[];
+ /**< Optional cache-line-aligned per-mbuf metadata area. */
};
Since this is a flexible array member, it does not change sizeof(struct
rte_mbuf). The object layout would become:
struct rte_mbuf fixed header
global per-mbuf metadata area
application private data
packet data buffer
With that layout, this could be sized at EAL init time rather than
by a build
option, for example:
--mbuf-metadata-size=256
Yes, that new proposal looks good to me.
One extra thing: I would like to repeat Morten there:
we probably do need similar mechanism for register/unregister/query that
dynamic metadata layout, as we have for mbuf dynfields now.
Might be we can extend existing mbuf_dynfield API?
or might be we can add a new API specific for this new metadata?
Right now I don't have strong opinion here.
Konstantin
That avoids creating different DPDK builds with different mbuf struct
sizes or
different build-time ABI expectations. The configured size would be
part of
the process/runtime configuration instead of requiring applications,
libraries, and package providers to agree on a compile-time define.
The official mbuf helpers would account for this area before ordinary
priv_size, so application private data remains available and does
not overlap
with the global metadata area.
This would also avoid changing the existing dynamic-field allocator
and copy
semantics. The area would not be part of the dynamic-field registry;
it would
be explicit per-mbuf metadata storage for applications that deliberately
enable it.
That seems to address the main concerns:
- sizeof(struct rte_mbuf) remains fixed for ABI purposes.
- the metadata area is globally present across pktmbuf pools when
enabled.
- ordinary priv_size remains separate and available.
- dynamic-field allocator/copy behavior remains unchanged.
- users that do not enable the EAL option pay no extra per-mbuf
storage cost.
- applications do not need to be built against a different mbuf-size
define.
If this direction is acceptable, I can take a look at what it means in
practice for EAL configuration, mbuf layout helpers, pool
constructors, and
places that currently do direct object-layout math.
Thanks,
-rt
*From: *Konstantin Ananyev <[email protected]>
*Date: *Tuesday, September 29, 2026 at 10:14 AM
*To: *Morten Brørup <[email protected]>; Randy Tice (rtice)
<[email protected]>; [email protected] <[email protected]>
*Cc: *Bruce Richardson <[email protected]>; Harman Kalra
<[email protected]>; Stephen Hemminger <[email protected]>
*Subject: *Re: [PATCH v3 1/1] mbuf: add optional no-copy dynamic field
storage
>> From: Konstantin Ananyev [mailto:[email protected]
<mailto:[email protected]>]
>> Sent: Tuesday, 29 September 2026 15.13
>>
>> 29.09.2026 13:44, Morten Brørup пишет:
>>>> From: Konstantin Ananyev [mailto:[email protected]
<mailto:[email protected]>]
>>>> Sent: Tuesday, 29 September 2026 14.00
>>>>
>>>> 28.09.2026 19:16, Randy L Tice пишет:
>>>>> From: Randy L Tice <[email protected]>
>>>>> 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.
> The private data area cannot be used.
> Let's say one module creates an mbuf pool with priv_size of 8, and
uses those 8 bytes,
> and some second module creates an mbuf pool with priv_size of 16,
and uses those 16 bytes.
>
> How should a module (or the application) know at which offset to
store its private data without overwriting the private data of other
modules?
>
> The mbuf dynamic field's registry manages centrally where each
module should store its own data, and the data is even accessible by
other modules (because they can fetch the offset to the data from the
registry)
ok, I see, you need an ability to register/unregister/query layout for
that private buffer (what we have now for dynfields).
Then yes, if we'll add an ability to expand mbuf dynfield[] buffer that
might be useful, and probably will become
more popular then current 'priv_size' apporach.
But I believe it shouldn't be a build time option.
>
>>> 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
