All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Ananyev <konstantin.ananyev@huawei.com>
To: "Morten Brørup" <mb@smartsharesystems.com>,
	"Andrew Rybchenko" <andrew.rybchenko@oktetlabs.ru>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: RE: mempool name size incorrect?
Date: Wed, 11 Mar 2026 10:52:11 +0000	[thread overview]
Message-ID: <144d8fcf192645e3aa240fc43d85097c@huawei.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F65777@smartserver.smartshare.dk>



> > On 3/10/26 5:10 PM, Morten Brørup wrote:
> > > Isn't the RTE_MEMPOOL_NAMESIZE too short?
> > >
> > > Looking at the names sizes:
> > >
> > > RTE_MEMZONE_NAMESIZE = 32,
> > > RTE_RING_NAMESIZE = RTE_MEMZONE_NAMESIZE - (sizeof("RG_")=4) + 1 =
> > 29,
> > > RTE_MEMPOOL_NAMESIZE = RTE_RING_NAMESIZE - (sizeof("MP_")=4) + 1 =
> 26
> > >
> > > Referring to [1], I think it should be fixed as:
> > > - #define RTE_MEMPOOL_NAMESIZE (RTE_RING_NAMESIZE - \
> > > 			      sizeof(RTE_MEMPOOL_MZ_PREFIX) + 1)
> > > + #define RTE_MEMPOOL_NAMESIZE (RTE_MEMZONE_NAMESIZE - \
> > > 			      sizeof(RTE_MEMPOOL_MZ_PREFIX) + 1)
> > >
> > > There is no ring involved, so I guess it is some kind of copy-paste-
> > search-replace error.
> > >
> >
> > I guess ring is involved in fact since the default mempool driver is
> > ring.
> >
> > See drivers/mempool/ring/rte_mempool_ring.c ring_alloc().
> >
> > Yes, it is not ideal, but at least it explains why RTE_RING_NAMESIZE
> > is used.
> 
> Thanks, that explains it. Bad layer violation...
> Let's hope no future mempool driver adds anything longer than "RG_" to the
> name of any memzone it creates.
> 
> Looking into the associated string length checks, using a too long name will fail
> with ENAMETOOLONG.
> So, using a long mempool name might succeed with some mempool drivers and
> fail with others. :-(
> 
> I guess there's no simple fix for that.
> And I was wrong to think that the RTE_MEMPOOL_NAMESIZE should be
> increased from 26 to 29.

As a generic thought: might be it is time to make the length across these
structs (mempool, ring, etc.) arbitrary?
At our next big API breakage or so.

> >
> > >
> > > Looking at the rte_mempool structure [2]:
> > > struct __rte_cache_aligned rte_mempool {
> > > 	char name[RTE_MEMPOOL_NAMESIZE]; /**< Name of mempool. */
> > > 	union {
> > > 		void *pool_data;         /**< Ring or pool to store
> > objects. */
> > > 		uint64_t pool_id;        /**< External mempool identifier.
> > */
> > > 	};
> > >
> > >
> > > Due to the 8-byte alignment of the pool_id field following the name
> > field, fixing the length as suggested doesn't change the memory layout
> > for 64 bit CPU architectures.
> > > But it does for 32 bit CPU architectures, which will only 4-byte
> > align the pool_id field.
> > >
> > > [1]: https://elixir.bootlin.com/dpdk/v26.03-
> > rc1/source/lib/mempool/rte_mempool.h#L128
> > > [2]: https://elixir.bootlin.com/dpdk/v26.03-
> > rc1/source/lib/mempool/rte_mempool.h#L230
> > >
> > >
> > > Another thing:
> > > On 32 bit CPU architectures, the cache_size and local_cache fields in
> > the rte_mempool structure are not in the same cache line.
> > > But I guess we don't really care about 32 bit CPU architectures.
> > >
> > >
> > > Venlig hilsen / Kind regards,
> > > -Morten Brørup
> > >


  reply	other threads:[~2026-03-11 10:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-10 14:10 mempool name size incorrect? Morten Brørup
2026-03-11  9:46 ` Andrew Rybchenko
2026-03-11 10:25   ` Morten Brørup
2026-03-11 10:52     ` Konstantin Ananyev [this message]
2026-03-11 10:57       ` Andrew Rybchenko
2026-03-11 11:08       ` Morten Brørup
2026-03-11 11:18         ` Konstantin Ananyev
2026-03-11 11:37           ` Morten Brørup
2026-03-12  8:37             ` Konstantin Ananyev
2026-03-11 15:58       ` Stephen Hemminger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=144d8fcf192645e3aa240fc43d85097c@huawei.com \
    --to=konstantin.ananyev@huawei.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=mb@smartsharesystems.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.