DPDK patches and discussions
 help / color / mirror / Atom feed
* [RFC] mbuf: performance optimization
@ 2024-01-21  5:32 Morten Brørup
  2024-01-21 17:07 ` Stephen Hemminger
  2024-01-22 14:27 ` [PATCH v2] mempool: test performance with larger bursts Morten Brørup
  0 siblings, 2 replies; 5+ messages in thread
From: Morten Brørup @ 2024-01-21  5:32 UTC (permalink / raw)
  To: dev; +Cc: andrew.rybchenko

What is the largest realistic value of mbuf->priv_size (the size of an mbuf's application private data area) in any use case?

I am wondering if its size could be reduced from 16 to 8 bit. If a max value of 255 isn't enough, then perhaps by knowing that the private data area must be aligned by 8 (RTE_MBUF_PRIV_ALIGN), its value can hold the size divided by 8. That would make the max value nearly 2 KB.

I suppose that reducing mbuf->nb_segs from 16 to 8 bit is realistic, considering that a maximum size IP packet (64 KB) is unlikely to use more than 64 plus some segments. Does anyone know of any use case with more than 255 segments in an mbuf?

These two changes would allow us to move mbuf->priv_size from the second to the first cache line.


Furthermore, mbuf->timesync should be a dynamic field. This, along with the above changes, would give us one more available 32-bit dynamic field.


Med venlig hilsen / Kind regards,
-Morten Brørup


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2024-01-22 14:39 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-21  5:32 [RFC] mbuf: performance optimization Morten Brørup
2024-01-21 17:07 ` Stephen Hemminger
2024-01-21 17:19   ` Morten Brørup
2024-01-22 14:27 ` [PATCH v2] mempool: test performance with larger bursts Morten Brørup
2024-01-22 14:39   ` Morten Brørup

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).