> From: Mattias Rönnblom [mailto:hof...@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.ronnb...@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.ronnb...@ericsson.com> > >> Acked-by: Morten Brørup <m...@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. > > > > > [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?
