2016-07-21 16:25, Olivier Matz: > On 07/21/2016 03:47 PM, Zoltan Kiss wrote: > > On 21/07/16 14:40, Olivier Matz wrote: > >> 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')) > > > > I was trying to figure out a compile time macro for strlen(postfix), but > > I could not. Your suggestion would work only until someone increases > > RTE_MAX_MEMZONE above 9999. As the likelihood of fragmenting a pool over > > 99 memzones seems small, I did not bother to fix this with an ugly hack, > > but if you think we should include it, let me know! > > Ok, looks fair, thanks for the clarification. > > Acked-by: Olivier Matz <olivier.matz at 6wind.com>
Applied, thanks