On Fri, 14 Aug 2026 14:12:11 +0200 Morten Brørup <[email protected]> wrote:
> > From: Stephen Hemminger [mailto:[email protected]] > > Sent: Thursday, 13 August 2026 19.13 > > > > This is a trial balloon to see what Morten's suggestion would > > look like. > > > > Increase memzone name size to 64 and reorder structure > > to keep it cache friendly. Move the zone name to the end of > > struct rte_memzone and order the remaining members by size. > > The structure is then naturally aligned > > with no internal padding on both 64-bit and 32-bit targets, so the > > __rte_packed_begin/end markers can be removed. > > > > With memzone size of 64 but don't need all that for stack names. > > Increase the size to 32 which adds some space without impacting > > cache layout. > > > > The memzone increase to 64 allows ring names to grow to 32 characters. > > Don't need to go larger which could cause cache changes when ring is > > embedded in structures. > > > > Bugzilla ID: 1984 > > > > Reported-by: Morten Brørup <[email protected]> > > Signed-off-by: Stephen Hemminger <[email protected]> > > --- > > Not as much as I hoped for, but non-intrusive. > A small improvement is still an improvement! > > Typo in the release notes: > "incre " -> "increased" > > Reviewed-by: Morten Brørup <[email protected]> > Only took baby first steps here. I asked AI for analysis on going further. On the question of going bigger than 64/32, here is what I found looking at the actual constraints in the tree. The memzone derivation is the artificial coupling ------------------------------------------------- rte_ring_lookup(), rte_mempool_lookup() and rte_stack_lookup() all walk their tailq and strncmp() against the object's own name field. None of them go through rte_memzone_lookup(). So RTE_MEMZONE_NAMESIZE does not bound anything functional; it only bounds the derived string "RG_%s" used to reserve the backing memzone, which is a debug label plus a uniqueness token. If the derived name became something like "RG_%.16s_%08x" /* truncated prefix + hash of full name */ then RTE_RING_NAMESIZE, RTE_STACK_NAMESIZE and RTE_MEMPOOL_NAMESIZE are decoupled from memzone entirely and both static_asserts go away. Each library's limit then becomes a storage-cost decision rather than an inherited one. Two things need handling: - Hash collisions make rte_memzone_reserve() fail with EEXIST, so the reserve path needs a retry with a disambiguating counter. - memzone dumps and telemetry output get less greppable. Keeping a truncated prefix of the real name mostly covers this. Self-relative offset instead of a flexible array ------------------------------------------------ Two of the blockers (embedded structures, structures that already have a flexible array) exist only because C requires a flexible array to be last. An offset has no position requirement: uint32_t name_off; /* byte offset from struct start to name */ This works when the struct is embedded (rte_event_ring wraps rte_ring), coexists with an existing trailing flexible array (rte_node_register is the case: name[RTE_NODE_NAMESIZE] plus next_nodes[]), and keeps the record fixed size so fbarray stride is preserved. A plain const char * would probably also work since rte_mempool already stores a const struct rte_memzone *mz into shared memory, but an offset avoids depending on identical secondary process mappings. Cost is source churn: every mz->name becomes rte_memzone_name(mz). Only 28 sites in tree, but out-of-tree consumers exist, so this wants a deprecation notice ahead of an ABI break release. Side table (least disruptive) ----------------------------- Keep the inline char name[N] untouched for compatibility and add a shared registry keyed by object index holding the full name only when it exceeds N. Lookup checks inline first, then the registry. No stride change, no ABI change, no flexible arrays, unlimited length. The tradeoff is that mz->name and r->name stay truncated for anything reading them directly, so it fixes lookup but not display. Numbers on ring growth ---------------------- Measured on x86-64: RTE_RING_NAMESIZE=32 sizeof(struct rte_ring)=384 prod at 128 RTE_RING_NAMESIZE=61 sizeof(struct rte_ring)=448 prod at 192 One extra cache line per ring plus a shifted hot region, inherited by rte_event_ring. That is the concrete argument for capping ring names at 32 rather than following memzone to 64. memzone is the opposite case: 104 bytes x 2560 default entries is about 266KB, so a larger fixed name there is nearly free. The fbarray stride constraint blocks variable-length names, not bigger ones.
