[DPDK/core Bug 1984] Increase memzone name size

[bugzilla@dpdk.org]

http://bugs.dpdk.org/show_bug.cgi?id=1984

            Bug ID: 1984
           Summary: Increase memzone name size
           Product: DPDK
           Version: 26.07
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: Normal
         Component: core
          Assignee: dev@dpdk.org
          Reporter: mb@smartsharesystems.com
  Target Milestone: ---

"32 bytes ought to be enough for anybody."
Said nobody.

Many object types have names, and at object creation, they create sub-objects,
adding a prefix to the name of the sub-object. The sub-objects may create its
own sub-objects (with another prefix added to the name) etc..

E.g. when creating a mempool named "example", the mempool lib creates a memzone
named "MP_example", and the mempool ring driver (a sub-object of the mempool)
creates a memzone named "RG_MP_example".

Assuming the FIB and RIB libs also added proper prefixes (which the currently
don't), the names would go:
"example" (FIB name),
"FIB_example" (RIB name),
"RIB_FIB_example" (mempool name),
"MP_RIB_FIB_example" (memzone name created by the mempool),
"RG_MP_RIB_FIB_example" (memzone name created by the ring driver).

One of the FIB6 test cases creates a FIB with the name "test_drift_compression"
(22 chars). Adding prefixes, it should end up being
"RG_MP_RIB_FIB_test_drift_compression" (36 chars).

I suggest increasing RTE_MEMZONE_NAMESIZE from 32 to 64.
This seems simple on the surface, as it does no harm to the rte_memzone
structure itself.

However, it has a ripple effect into other object types, whose name sizes are
derived by this, e.g. the rte_ring and the rte_mempool structures.
When the size of the name field in those structures is increased, other fields
in the structures will move down, and may end up in a different cache line.
So, all structures depending on RTE_MEMZONE_NAMESIZE must be carefully reviewed
and adjusted, so their fields are grouped efficiently, considering cache lines.

-- 
You are receiving this mail because:
You are the assignee for the bug.