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: [email protected]
Reporter: [email protected]
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.