Hi Zoltan,
On 07/20/2016 07:16 PM, Zoltan Kiss wrote: > A recent patch brought up an issue about the size of the 'name' fields: > > 85cf0079 mem: avoid memzone/mempool/ring name truncation > > These relations should be observed: > > 1. Each ring creates a memzone with a prefixed name: > RTE_RING_NAMESIZE <= RTE_MEMZONE_NAMESIZE - strlen(RTE_RING_MZ_PREFIX) > > 2. There are some mempool handlers which create a ring with a prefixed > name: > RTE_MEMPOOL_NAMESIZE <= RTE_RING_NAMESIZE - strlen(RTE_MEMPOOL_MZ_PREFIX) > > 3. A mempool can create up to RTE_MAX_MEMZONE pre and postfixed memzones: > sprintf(postfix, "_%d", RTE_MAX_MEMZONE) > RTE_MEMPOOL_NAMESIZE <= RTE_MEMZONE_NAMESIZE - > strlen(RTE_MEMPOOL_MZ_PREFIX) - strlen(postfix) > > Setting all of them to 32 hides this restriction from the application. > This patch decreases the mempool and ring string size to accommodate for > these prefixes, but it doesn't apply the 3rd constraint. Applications > relying on these constants need to be recompiled, otherwise they'll run > into ENAMETOOLONG issues. > The size of the arrays are kept 32 for ABI compatibility, it can be > decreased next time the ABI changes. > > Signed-off-by: Zoltan Kiss <zoltan.kiss at schaman.hu> Looks like to be a good compromise for the 16.07 release. One question however: why not taking in account the 3rd constraint? Because it may not completly fix the issue if the mempool is fragmented. We could define RTE_MEMPOOL_NAMESIZE to 24 = 32 - len('mp_') - len('_0123')) Thanks, Olivier