On Wed, Mar 06, 2024 at 10:55:36AM +0100, David Marchand wrote:
> Hello Tyler,
>
> On Mon, Mar 4, 2024 at 6:53 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.
> >
> > For variables standard C11 offers alignas(a) supported by conformant
> > compilers i.e. both MSVC and GCC.
> >
> > For types the standard offers no alignment facility that compatibly
> > interoperates with C and C++ but may be achieved by relocating the
> > placement of __rte_aligned(a) to the aforementioned location accepted
> > by all currently supported toolchains.
> >
> > ** NOTE **
> >
> > Finally, In the interest of not creating more API (internal or not) the
> > series does not introduce a wrapper for C11 alignas. If we don't introduce
> > a macro an application can't take a dependency.
>
> I reorganised the commits since those were global/mechanical changes in lib/.
>
> As part of the alignas() conversion, I updated the references to
> __rte_*aligned in the documentation so that there is no "bad example"
> in doc/.
>
> I converted the cacheline1 field to alignas in the mbuf library, but
> also in eventdev and security libraries.
> With this, there is no remaining construct like struct|union { ... }
> __rte_*aligned in lib/.
>
> I added a check in checkpatches.sh so that we don't reintroduce
> wrongly placed __rte_*aligned tags.
> I made this check global (iow not restricted to lib/) so that
> developers touching drivers/ and other parts of DPDK are made aware of
> this change of use of __rte_*aligned tags.
>
> Series applied.
Great to have this done, thank you David!
>
> --
> David Marchand
