Hi Georg, > 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.
Thank you for pointing this out. That's an excellent comment and something I had missed. Would adding the __may_alias__ attribute to the unaligned_uint structs fix the issue? I think it would, but I have to admit that documentation is a little sparse and I don't have much experience with this attribute. If it doesn't fix the problem, please let me know if you can think of another solution that wouldn't involve going back to assembly (v4 of this patch). Also, I think the __may_alias__ attribute is supported by all compilers that DPDK supports when targeting x86, but please let me know if you don't think that's the case. > BTW, are there still systems that DPDK supports but have a memcpy() which > performs worse than rte_memcpy()? I concur with Morten, that's an excellent question. Analyzing the memcpy source code on every platform/architecture that DPDK supports would be one way to answer the question. However, that seems like a significant undertaking and I'm hoping someone who knows the answer will chime in.
