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.
--
David Marchand
