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.
