[PATCH] RFC: use C11 alignas instead of GCC attribute aligned
Mattias Rönnblom
hofors at lysator.liu.se
Tue Jan 30 19:18:46 CET 2024
On 2024-01-30 18:59, Bruce Richardson wrote:
> On Tue, Jan 30, 2024 at 09:39:28AM -0800, Tyler Retzlaff wrote:
>> On Tue, Jan 30, 2024 at 09:08:21AM +0100, Mattias Rönnblom wrote:
> <snip>
>>>
>>> Sorry if I've missed some discussion on the list, but the current
>>> pattern of putting __rte_aligned(X) at the end doesn't work with MSVC,
>>> or why are we doing this? C11 purism doesn't seem like much of a
>>> driving force.
>>
>> __rte_aligned(X) at the end doesn't work with MSVC __declspec(align(n))
>>
>>>
>>> If one defined a macro as __declspec(align(X)) on MSVC and
>>> __attribute__(__aligned__(X)) on other compilers, could it do the work
>>> of both the above RTE_ALIGNAS() and RTE_ALIGN_TYPE()?
>>>
>>> <a> struct <b> { int a; } <c>;
>>
>> yes for struct/union. but only when placed at location you mark as <b>
>> when compiling both C and C++ for all toolchains.
>>
> I can see this restriction on placement potentially causing problems. Maybe
> we should consider defining macros with the "struct" keywork included. For
> example, (using gcc attributes here):
>
> #define rte_aligned_struct(n) struct __attribute((aligned(n)))
>
> rte_aligned_struct my_struct {
> int a;
> }
>
> Probably that's taking things a bit far away from standard C, but it may
> cut down on placement errors.
It doesn't go well with the fact alignment is just one of several
attributes one may want to add to a struct (__rte_packed is another).
A quick scan of the DPDK source tree suggests DPDK developers are pretty
good at putting the old __rte_cache_aligned consistently after the
struct declaration (i.e., position <c> per above). Conservative as they
may be, perhaps they could be rewired to consistently put it somewhere else.
More information about the dev
mailing list