On Wed, Mar 20, 2024 at 06:41:30PM +0100, David Marchand wrote: > Hello Tyler, > > On Wed, Mar 20, 2024 at 4:38 PM Tyler Retzlaff > <roret...@linux.microsoft.com> wrote: > > > > The current location used for __rte_aligned(a) for alignment of types > > and variables is not compatible with MSVC. There is only a single > > location accepted by both toolchains. > > > > After having established this as the conventional standard for lib/* > > this series is intended to convert the remainder of the source tree to > > use the same location for __rte_aligned(a) and alignas(a) for > > consistency. > > The series looks good to me. > > We may have some misses because of drivers wrapping in their own > stuff, but I am not sure those are fixable (this touches some base > drivers..) > drivers/common/cnxk/roc_platform.h:#define __plt_aligned __rte_aligned > drivers/common/dpaax/compat.h:#define ____cacheline_aligned > __rte_aligned(L1_CACHE_BYTES) > drivers/common/cnxk/roc_platform.h:#define __plt_cache_aligned > __rte_cache_aligned > drivers/net/ena/base/ena_plat_dpdk.h:#define ____cacheline_aligned > __rte_cache_aligned > drivers/net/gve/base/gve_osdep.h:#define ____cacheline_aligned > __rte_cache_aligned
Yes, I know about these and I made the call to leave them untouched for now. The cnxk drivers aren't built on windows and i didn't want to interfere with some out of tree abstraction they may be using for testing. > > I also noticed memif: > drivers/net/memif/memif.h:typedef struct __rte_packed __rte_aligned(128) This should be okay, I also have to address __rte_packed (series coming soon). So long as there are no objections I would propose this series merged as soon as possible (after release) assuming CI doesn't identify anything of concern. if there is follow up to do with cnxk/dpaax i'm happy to do it as a separate series. ty
