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

[Mattias Rönnblom]

On 2024-10-10 13:47, Morten Brørup wrote:
>> From: Mattias Rönnblom [mailto:hofors at lysator.liu.se]
>> Sent: Thursday, 10 October 2024 12.40
>>
>> On 2024-10-10 00:15, Morten Brørup wrote:
>>>> From: Mattias Rönnblom [mailto:mattias.ronnblom at ericsson.com]
>>>> Sent: Wednesday, 18 September 2024 10.26
>>>>
>>>> Introduce DPDK per-lcore id variables, or lcore variables for short.
>>>>
>>>> An lcore variable has one value for every current and future lcore
>>>> id-equipped thread.
>>>>
>>>> The primary <rte_lcore_var.h> use case is for statically allocating
>>>> small, frequently-accessed data structures, for which one instance
>>>> should exist for each lcore.
>>>>
>>>> Lcore variables are similar to thread-local storage (TLS, e.g., C11
>>>> _Thread_local), but decoupling the values' life time with that of
>> the
>>>> threads.
>>>>
>>>> Lcore variables are also similar in terms of functionality provided
>> by
>>>> FreeBSD kernel's DPCPU_*() family of macros and the associated
>>>> build-time machinery. DPCPU uses linker scripts, which effectively
>>>> prevents the reuse of its, otherwise seemingly viable, approach.
>>>>
>>>> The currently-prevailing way to solve the same problem as lcore
>>>> variables is to keep a module's per-lcore data as RTE_MAX_LCORE-
>> sized
>>>> array of cache-aligned, RTE_CACHE_GUARDed structs. The benefit of
>>>> lcore variables over this approach is that data related to the same
>>>> lcore now is close (spatially, in memory), rather than data used by
>>>> the same module, which in turn avoid excessive use of padding,
>>>> polluting caches with unused data.
>>>>
>>>> Signed-off-by: Mattias Rönnblom <mattias.ronnblom at ericsson.com>
>>>> Acked-by: Morten Brørup <mb at smartsharesystems.com>
>>>
>>>> --- /dev/null
>>>> +++ b/lib/eal/common/eal_common_lcore_var.c
>>>> @@ -0,0 +1,79 @@
>>>> +/* SPDX-License-Identifier: BSD-3-Clause
>>>> + * Copyright(c) 2024 Ericsson AB
>>>> + */
>>>> +
>>>> +#include <inttypes.h>
>>>> +#include <stdlib.h>
>>>> +
>>>> +#ifdef RTE_EXEC_ENV_WINDOWS
>>>> +#include <malloc.h>
>>>> +#endif
>>>
>>>   From what I can read on the internet, max_align_t is missing in
>> stddef.h in MSVC [1], so try adding this to fix the Windows CI
>> compilation failure:
>>>
>>> #ifdef RTE_TOOLCHAIN_MSVC
>>> #include <cstddef>
>>> #endif
>>
>> Please excuse my MSVC ignorance, but will this work in C? Looks like
>> C++.
> 
> I have no clue. Just parroting what Microsoft says on the internet.
> 
> You can try it out and see if the CI accepts it.
> 

It wouldn't make sense if that worked, so I'll go for this instead:

#ifdef RTE_TOOLCHAIN_MSVC
		/* MSVC <stddef.h> is missing the max_align_t typedef */
		align = alignof(double);
#else
		align = alignof(max_align_t);
#endif

Thanks for pointing out this issue.

>>
>>>
>>> [1]: https://learn.microsoft.com/en-ie/answers/questions/1726147/why-
>> max-align-t-not-defined-in-stddef-h-in-windows
>>>
> 
> I would like to see this series go into 24.11, and then it needs to work for MSVC too.
> 
> @Tyler, any better suggestions for fixing the missing max_align_t in stddef.h?
>