Re: [PATCH 00/83] move alignment attribute on types

[Tyler Retzlaff <roretzla@linux.microsoft.com>]

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
> <roretzla@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