[PATCH v4 0/1] mbuf: add runtime metadata dynamic-field storage

[Morten Brørup]

> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Friday, 9 October 2026 21.16
> 
> On Fri, 9 Oct 2026 18:12:20 +0000
> "Randy Tice (rtice)" <rtice at cisco.com> wrote:
> 
> > Stephen,
> > I’m thinking, perhaps the best path forward for now, is to continue
> using a private mbuf layout and carry the collateral internally — at
> least for now. The changes are getting well beyond the initial desired
> impacts and has potential make things become unstable.
> >
> > I would love to see some sort of solution along these lines in the
> future so we can discontinue the use of a private patch. To be clear,
> the solution is not built around cnxk, cnxk is just impacted — we have
> several other platform builds that do not use cnxk but we still carry
> the metadata in the mbuf itself for performance reasons.
> >
> > WRT the skip functions, we fit under the 384 max for wqe but there’s
> no room for additional growth beyond that with how it’s laid out. The
> other 2 are not as sensitive to the size but still have valid limits
> which are well beyond our use case. Today we carry 256 bytes which caps
> us on wqe.
> >
> > That said, we plan to discuss internally next week on how to move
> forward as we prep for our v25.11 upgrade work. I want to thank you and
> Morten, however, for your time and support on this work.
> > Regards,
> > -rt
> 
> I do think CNXK needs fixing.

I would like to see this feature go into the mbuf library.
A lot of effort has been put into making it generally useful.
Unfortunately, it is probably too late for 26.11, but maybe 27.11.

IMO, if one NIC driver has weird behavior or assumptions, it should not be a barrier to extending the mbuf library with this new feature.
Especially if the driver can be fixed.
My opinion would be different if many drivers were incompatible.

Furthermore, fixing a driver with weird behavior (or weird assumptions) should not be the job of someone contributing to a core library!
I think it is great that Randy identified the CNXK driver issue.
And I consider it a perfectly reasonable workaround to say that the driver is not compatible with this feature, so either don't use the feature, or don't use the driver.

If the driver hasn't been fixed by the time this feature gets into an LTS release, the driver can be fixed in any later (non-LTS) release, and the incompatibility workaround can be removed at that point.

-Morten