[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