<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<a href="mailto:mb@smartsharesystems.com" id="OWAAM342110" rel="noreferrer noopener" data-outlook-id="5bfa4e5f-23ee-4f1e-9023-6ff7d5884740">@Morten Brørup</a></div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  Hi Morten,</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  I wanted to ask one follow-up question before sending the dynfield3 patch.</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  The current patch direction adds a build-time sized, cache-line-aligned</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  dynfield3 area to struct rte_mbuf. My initial thought was to keep that area</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  reserved but outside the dynamic mbuf field allocator, with ownership and copy</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  semantics left to the application that enables it.</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  The reason is compatibility with the existing downstream use case we are trying</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  to replace. Today, our Cisco-specific pktmetadata area is embedded in struct</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  rte_mbuf and is initialized from the mbuf pool init path. It stores packet</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  ownership/linkage state, not ordinary copied packet metadata.</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  One important detail is that pktmetadata is not copied today by generic DPDK</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  mbuf clone/copy paths. Those paths do not copy struct rte_mbuf wholesale; they</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  copy selected header fields and then explicitly copy the official dynamic-field</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  backing areas through rte_mbuf_dynfield_copy(). Since pktmetadata was not part</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  of that helper, clone, attach, and copy did not duplicate that ownership</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  state.</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  If dynfield3 is exposed through the dynamic mbuf field allocator, I think it</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  would naturally also need to be included in rte_mbuf_dynfield_copy(), matching</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  the existing dynfield1/dynfield2 behavior. That makes sense for normal dynamic</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  fields, but it changes the semantics for this use case: generic clone/copy</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  would duplicate packet ownership metadata that previously was not copied.</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  Given that, would you still prefer dynfield3 to be allocator-managed, or would</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  it be acceptable for this build-time configured area to remain reserved storage</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  outside the allocator, with copy semantics owned by the application that</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  enables it?</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  If allocator management is preferred, we can adapt on our side by reserving the</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  full area early during initialization and requiring Cisco wrappers around any</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  future mbuf clone/copy use so the area can be cleared or reinitialized. But I</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  wanted to check whether keeping it out of the allocator is reasonable first,</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  because that better preserves the behavior of the downstream pktmetadata area</div>
<div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
  this is intended to replace.</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thanks,</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
-rt</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="mail-editor-reference-message-container">
<div style="padding: 3pt 0in 0in; border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) currentcolor currentcolor;">
<div style="text-align: left; font-family: Aptos; font-size: 12pt; color: black;">
<b>From: </b>Randy Tice (rtice) <rtice@cisco.com><br>
<b>Date: </b>Tuesday, September 1, 2026 at 1:01 PM<br>
<b>To: </b>Morten Brørup <mb@smartsharesystems.com>; dev@dpdk.org <dev@dpdk.org>; Stephen Hemminger <stephen@networkplumber.org>; Konstantin Ananyev <konstantin.ananyev@huawei.com><br>
<b>Subject: </b>Re: [RFC] mbuf: add configurable base private size for pktmbuf pools<br>
<br>
</div>
</div>
<div id="mail-editor-reference-message-body">
<div class="ms-outlook-mobile-reference-message skipProofing" style="direction: ltr;">
</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Morten,</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thanks, this helps clarify the intended direction.</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
My concern with a dynfield3-style area was not the mechanics of accessing the</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
field. It was whether a comparatively large application-defined mbuf area fit</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
the intended policy for the existing dynfield support.</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Our requirement is for a contiguous per-mbuf metadata area that is cache-line</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
aligned. Private data satisfied that shape directly, which is why we started</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
there. If you're agreeable to extending the existing dynfield support this</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
way, that would be a significantly smaller and cleaner approach forward.</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
The size does need to be configurable. We use the same DPDK package across</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
multiple platforms, including both 32-bit and 64-bit applications, and the</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
per-mbuf size requirement is not necessarily the same across those builds. A</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
fixed expansion would force every consumer to pay the same memory cost.</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
This also has a useful implementation benefit: if the extra area is accounted</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
for centrally in the mbuf layout/init path, then PMD-managed pools outside the</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
normal pktmbuf create API do not need separate private-size fixups. Existing</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
per-pool private data can remain separate and continue to serve pool-specific</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
users.</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
With that framing, I am comfortable pursuing this direction.</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thank you very much!</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Regards,</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
-rt</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="mail-editor-reference-message-container">
<div style="padding: 3pt 0in 0in; border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) currentcolor currentcolor;">
<div style="text-align: left; font-family: Aptos; font-size: 12pt; color: black;">
<b>From: </b>Morten Brørup <mb@smartsharesystems.com><br>
<b>Date: </b>Tuesday, September 1, 2026 at 12:36 PM<br>
<b>To: </b>Randy Tice (rtice) <rtice@cisco.com>; dev@dpdk.org <dev@dpdk.org>; Stephen Hemminger <stephen@networkplumber.org>; Konstantin Ananyev <konstantin.ananyev@huawei.com><br>
<b>Subject: </b>RE: [RFC] mbuf: add configurable base private size for pktmbuf pools<br>
<br>
</div>
</div>
<div id="mail-editor-reference-message-body">
<div class="ms-outlook-mobile-reference-message skipProofing" style="direction: ltr;">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
</div>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);"><a name="_MailEndCompose" data-outlook-id="9deb4516-b1a1-485e-8684-3f4408a90018" style="margin-top: 0px; margin-bottom: 0px;">Randy,</a></span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);">Did you look at the Dynamic Mbuf Fields API?</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);">You can reserve a large chunk as an mbuf dynamic field. It will be contiguous.</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);">You can also specify alignment when allocating a field.</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);">Maybe the size of the dynfield3 area should be run-time configurable; I addressed that option at the end of my original reply.</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);">Unless there’s some subtle point I’m misunderstanding, I’m confident Dynamic Mbuf Fields is the right solution for your use case.</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);">As the mbuf maintainer, I would welcome such an addition to the Dynamic Mbuf Fields library.</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);">Venlig hilsen / Kind regards,</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);">-Morten Brørup</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<div style="padding: 0cm 0cm 0cm 4pt; border-width: medium medium medium 1.5pt; border-style: none none none solid; border-color: currentcolor currentcolor currentcolor blue;">
<div style="padding: 3pt 0cm 0cm; border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) currentcolor currentcolor;">
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Tahoma, sans-serif; font-size: 10pt;"><b>From:</b> Morten Brørup<br>
<b>Sent:</b> Tuesday, 1 September 2026 18.23<br>
<b>To:</b> 'Randy Tice (rtice)'; dev@dpdk.org; Stephen Hemminger; Konstantin Ananyev<br>
<b>Subject:</b> RE: [RFC] mbuf: add configurable base private size for pktmbuf pools</span></p>
</div>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
 </p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);">Randy,</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);">I don’t understand why you don’t like my proposed solution.</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);">What is the difference between adding 384 bytes to all mbufs as an extra dynfield3, compared to adding 384 bytes to all mbufs through application_base_priv?</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);">The extra 384 bytes will be located at the same position relative to the mbuf (between the rte_mbuf structure and the priv_data area), and will use the same amount of
 memory for all mbufs.</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);">You propose splitting the priv_data area into two parts: One globally sized area for all mbuf pools (configured through the EAL option), and one per-mempool sized area,
 configured at pktmbuf-pool creation.</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);">Then the global priv_data part does exactly the same the Dynamic Mbuf Fields does.</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);">There is no reason to introduce another method for doing something an existing API already does.</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);">It’s better to expand the implementation of the existing API.</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);">Venlig hilsen / Kind regards,</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);">-Morten Brørup</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<div style="padding: 0cm 0cm 0cm 4pt; border-width: medium medium medium 1.5pt; border-style: none none none solid; border-color: currentcolor currentcolor currentcolor blue;">
<div style="padding: 3pt 0cm 0cm; border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) currentcolor currentcolor;">
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Tahoma, sans-serif; font-size: 10pt;"><b>From:</b> Randy Tice (rtice) [mailto:rtice@cisco.com]<br>
<b>Sent:</b> Tuesday, 1 September 2026 17.44<br>
<b>To:</b> Morten Brørup; dev@dpdk.org; Stephen Hemminger; Konstantin Ananyev<br>
<b>Subject:</b> Re: [RFC] mbuf: add configurable base private size for pktmbuf pools</span></p>
</div>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
 </p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">Morten,</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">Thanks for the detailed response. I went back through our requirements and the</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">current mbuf layout, and I believe our use case maps better to private data.</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;"> </span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">The metadata area we need today is roughly 384 bytes per mbuf. It needs to be</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">contiguous, cache-aligned, and available consistently across the packet mbuf</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">pools used by the platform.</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;"> </span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">The existing reserved areas in struct rte_mbuf do not fit that shape.</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">dynfield1[9] is only 36 bytes and is not cache-line aligned as a standalone</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">area. dynfield2 is only 8 bytes and is configuration-dependent: it exists only</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">when RTE_IOVA_IN_MBUF is 0, meaning the IOVA value is not carried in the mbuf.</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">When RTE_IOVA_IN_MBUF is 1, that mbuf slot is used for other layout state and</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">dynfield2 is absent. So even using those fields directly, they are not large</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">enough or consistent enough for this metadata overlay.</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;"> </span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">We could add a larger reserved area such as the proposed dynfield3, but it</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">would have to be size-adjustable. Not every application would want another</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">fixed 384 bytes in every mbuf, and our own requirement has already moved from</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">256 to 384 bytes for 64-bit applications, so the size may continue to evolve.</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">That makes a fixed mbuf-struct expansion a poor fit.</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;"> </span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">The existing private data area already exists for this kind of use case:</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">contiguous per-mbuf storage adjacent to the mbuf object, with sizing handled</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">as part of mbuf pool creation. The issue we are trying to solve is that</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">priv_size is currently pool-specific, while our common packet metadata needs a</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">base area available across all packet mbuf pools. The proposed patch adds that</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">common base private size through the standard packet mbuf pool creation</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">helpers. Pool-specific private data can still be added on top when needed.</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;"><br>
So, for this use case, private data is the cleaner and more direct fit.<br>
Thanks,</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;">-rt</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;"> </span></p>
<div id="mail-editor-reference-message-container">
<div style="padding: 3pt 0cm 0cm; border-width: 1pt medium medium; border-style: solid none none; border-color: currentcolor;">
<p class="MsoNormal" style="margin: 0cm 0cm 12pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-family: Aptos, serif; color: black;"><b>From: </b>Morten Brørup <mb@smartsharesystems.com><br>
<b>Date: </b>Tuesday, September 1, 2026 at 7:11 AM<br>
<b>To: </b>Randy Tice (rtice) <rtice@cisco.com>; dev@dpdk.org <dev@dpdk.org>; Stephen Hemminger <stephen@networkplumber.org>; Konstantin Ananyev <konstantin.ananyev@huawei.com><br>
<b>Subject: </b>RE: [RFC] mbuf: add configurable base private size for pktmbuf pools</span></p>
</div>
<div id="mail-editor-reference-message-body">
<p class="MsoNormal" style="margin: 0cm 0cm 12pt; font-family: "Times New Roman", serif; font-size: 12pt;">
<span style="font-size: 11pt;">> From: Randy Tice (rtice) [</span><span style="font-size: 11pt; color: blue;"><a href="mailto:rtice@cisco.com" data-outlook-id="7ff1eedb-f5a6-4bbd-a6a7-ceee902d985d" style="color: blue; margin-top: 0px; margin-bottom: 0px;"><u>mailto:rtice@cisco.com</u></a></span><span style="font-size: 11pt;">]<br>
> Sent: Monday, 31 August 2026 20.20<br>
><br>
> Hi,<br>
> I would like to get feedback on a proposed mbuf change before sending patches.<br>
> Some deployments need a guaranteed private-data reservation in every packet mbuf, across multiple mbuf pools and across different consumers of the mbuf APIs.<br>
> 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.<br>
> 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.<br>
> 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.<br>
> The proposed generic model is to add a configurable base private size for pktmbuf pools. The effective private size would be:<br>
> align(pool_requested_priv_size + application_base_priv_size,<br>
>       RTE_MBUF_PRIV_ALIGN)<br>
> The tentative EAL option name is:<br>
> --mbuf-base-priv-size=<size><br>
> The intent is:<br>
> * default behavior remains unchanged when the option is not used;<br>
> * the configured base size is added to the private size requested by each pktmbuf pool;<br>
> * the final effective private size remains aligned to RTE_MBUF_PRIV_ALIGN;<br>
> * pool-specific private-data requests still work as they do today;<br>
> * DPDK centralizes the policy so pools created outside application control can reserve the same base private-data space as application-created pools.<br>
> This is not intended to define ownership or layout of the private area. It only ensures that a deployment can reserve a common base amount of private data consistently. Applications, drivers, libraries, or components would still be responsible for their own
 interpretation of the reserved private area.<br>
> Questions for the list:<br>
> 1. Is a deployment-wide pktmbuf base private-size reservation something DPDK would consider acceptable?<br>
> 2. Is --mbuf-base-priv-size=<size> a reasonable name, or would another name better describe the intent?<br>
> 3. Should DPDK expose the effective-size calculation as a helper so pool-creation paths outside application control can apply the same rule?<br>
> 4. Would maintainers prefer consumer updates in the same series as example users, or as follow-up patches after the generic mbuf/EAL change is accepted?<br>
> 5. Would maintainers prefer this to remain component-specific, even if more than one driver, library, or pool-creation path may need to apply the same base reservation?<br>
> The main goal is to avoid downstream mbuf layout changes and avoid component-specific configuration drift, while still allowing deployments to reserve a consistent private-data area across all packet mbuf pools, including pools created outside direct application
 control.<br>
> Thanks,<br>
> Randy<br>
<br>
DPDK already has Dynamic Mbuf Fields for run-time management of private data across all mbuf pools.<br>
DPDK also has the Private Data Area (priv_size), but that is individual to each mbuf pool, which does not fit your use case.<br>
<br>
Dynamic Mbuf Fields is the perfect fit for the use case you are describing.<br>
<br>
Currently, it only manages a few small memory areas inside the rte_mbuf structure itself, the dynfield1 array and the dynfield2 field.<br>
But it could easily manage one more memory area associated with the rte_mbuf structure.<br>
<br>
If we want this to be build-time configurable, it should be relatively simple to add:<br>
<br>
In config/rte_common.h:<br>
+#define RTE_MBUF_DYN_EXTRA_SIZE 128<br>
<br>
In lib/mbuf/rte_mbuf_core.h:<br>
        /** Size of the application private data. In case of an indirect<br>
         * mbuf, it stores the direct mbuf private data size.<br>
         */<br>
        uint16_t priv_size;<br>
<br>
        /** Timesync flags for use with IEEE1588. */<br>
        uint16_t timesync;<br>
<br>
        uint32_t dynfield1[9]; /**< Reserved for dynamic fields. */<br>
+<br>
+#if RTE_MBUF_DYN_EXTRA_SIZE<br>
+       /** Extra dynamic fields. */<br>
+       uint32_t dynfield3[RTE_MBUF_DYN_EXTRA_SIZE / sizeof(uint32_t)];<br>
+#endif<br>
};<br>
<br>
In lib/mbuf/rte_mbuf_dyn.h:<br>
+static_assert(RTE_MBUF_DYN_EXTRA_SIZE % RTE_CACHE_LINE_SIZE == 0,<br>
+       "RTE_MBUF_DYN_EXTRA_SIZE must be multiple of cache line size.");<br>
<br>
And some associated additions in lib/mbuf/rte_mbuf_dyn.c.<br>
<br>
<feature creep><br>
<br>
There may also be considerations about what happens to the extra data when:<br>
- Copying an mbuf.<br>
- Attaching an mbuf to another mbuf.<br>
- Detaching an mbuf from another mbuf.<br>
- Cloning an mbuf.<br>
<br>
(The considerations apply to both the packet mbuf itself, and for the non-first segments of a segmented packet mbuf.)<br>
<br>
The developer of the Dynamic Mbuf Fields library was foreseeable enough to add a "flags" parameter for dynamic mbuf field creation.<br>
This could be used to specify what happens to each registered dynamic field in the events enumerated above.<br>
<br>
</feature creep><br>
<br>
IMO, the extended size of Dynamic Mbuf Fields should be build-time configurable.<br>
<br>
If the community wants the extended size of Dynamic Mbuf Fields run-time configurable, the size should be an EAL startup parameter.<br>
It could be named: --mbuf-dyn-extra-size=<size>.<br>
The major difference in implementation is that the space for the extra dynfields must be dynamically allocated with the mbufs at mbuf pool creation.<br>
Notice that the memory for the extra dynfields should be positioned between the mbuf structure and the private data area, so their offsets remain the same, also for two mbuf pools having different Private Data Area sizes.<br>
<br>
-Morten</span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>