[PATCH v13 1/7] eal: add static per-lcore memory allocation facility

Mattias Rönnblom hofors at lysator.liu.se
Tue Oct 15 21:02:47 CEST 2024


On 2024-10-15 12:13, Morten Brørup wrote:
>> +void *
>> +rte_lcore_var_alloc(size_t size, size_t align)
>> +{
>> +	/* Having the per-lcore buffer size aligned on cache lines
>> +	 * assures as well as having the base pointer aligned on cache
>> +	 * size assures that aligned offsets also translate to alipgned
>> +	 * pointers across all values.
>> +	 */
>> +	RTE_BUILD_BUG_ON(RTE_MAX_LCORE_VAR % RTE_CACHE_LINE_SIZE != 0);
>> +	RTE_VERIFY(align <= RTE_CACHE_LINE_SIZE);
>> +	RTE_VERIFY(size <= RTE_MAX_LCORE_VAR);
>> +
>> +	/* '0' means asking for worst-case alignment requirements */
>> +	if (align == 0)
>> +#ifdef RTE_TOOLCHAIN_MSVC
>> +		/* MSVC <stddef.h> is missing the max_align_t typedef */
>> +		align = alignof(double);
>> +#else
>> +		align = alignof(max_align_t);
>> +#endif
> 
> Do we need worst-case alignment, or does automatic alignment suffice:
> 

I think the term is "natural alignment." As I think I mentioned at some 
point, I don't really have an opinion.

Worst case (max_alignt_t) alignment is the same as malloc(), so 
potentially what the user may expect. On the other hand, I can't see why 
natural alignment (or alignof(max_align_t), whichever is smallest) would 
not always suffice. It is a bit harder to explain in the API docs what 
alignment you actually get in case you don't go for worst-case alignment.

I think it doesn't matter much, because the user will very likely use 
the typed macros (and get whatever alignment the compiler deems 
appropriate for that type).

> 	/* '0' means asking for automatic alignment requirements */
> 	if (align == 0) {
> #ifdef RTE_ARCH_64
> 		align = rte_align64pow2(size);
> #else
> 		align = rte_align32pow2(size);
> #endif
> #ifdef RTE_TOOLCHAIN_MSVC
> 		/* MSVC <stddef.h> is missing the max_align_t typedef */
> 		align = RTE_MIN(align, alignof(double));
> #else
> 		align = RTE_MIN(align, alignof(max_align_t));
> #endif
> 	}
> 
> It will pack small-size lcore variables even tighter.
> 



More information about the dev mailing list