Hello, Stephen Hemminger wrote (Sun, 16 Jan 2022 08:32:20 -0800):
> I would propose that DPDK have same kind of define as the kernel > for SAFE_UNALIGNED_ACCESS. The C standard has to apply to all architectures > but DPDK will make the choice to be fast rather than standards conformant. perhaps it's worth mentioning that the Linux Kernel is compiled with -fno-strict-aliasing, because it contains code which violates the C strict aliasing rules. Such code yields undefined behavior and is thus unsafe when compiling with optmizing compilers such as GCC and Clang, by default. But since the Linux supplies -fno-strict-aliasing its code is safe, in the Linux Kernel context. In contrast, DPDK isn't compiled with -fno-strict-aliasing, in general. Only a few drivers are built with -Wno-strict-aliasing. Thus, one has to be careful when importing (or being inspired) by the above mentioned kernel defines. Especially, it looks like version 5 of this patch yields undefined behavior because it violates strict-aliasing rules. It's possible that GCC makes some extra guarantees for the used constructs, even when compiling without -fno-strict-aliasing. But I'm not aware of any. Please note that there is a reason GCC enables -fstrict-aliasing when compiling with optimizations: Performance IOW, -fno-strict-aliasing has performance implications, thus one is advised to not use it, if possible. IOW, when violating strict-aliasng rules one can easily end up with low-performing and/or unsafe (buggy) code. I haven't inspected the DPDK drivers which supply -Wno-strict-aliasing - but I wouldn't be surprised if there aren't better alternatives. Meaning writing the code in a way that doesn't require -Wno-strict-aliasing. BTW, are there still systems that DPDK supports but have a memcpy() which performs worse than rte_memcpy()? Best regards, Georg
