From: Konstantin Ananyev [mailto:[email protected]]
Sent: Tuesday, 29 September 2026 15.13
29.09.2026 13:44, Morten Brørup пишет:
From: Konstantin Ananyev [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
