On Sat, 17 Feb 2024 15:22:12 +0100 Laurent Vivier <lvivier(a)redhat.com> wrote:On 2/16/24 19:24, Stefano Brivio wrote:I guess in practice yes, but it could be formally complicated for a compiler to make sure no instructions dereferencing those pointers will be emitted, plus this is on the packet path and if the compiler decides to *not* inline, we shouldn't force that.On Fri, 16 Feb 2024 19:05:39 +0100 Laurent Vivier <lvivier(a)redhat.com> wrote: ...I can imagine 4 solutions: * to use inline functions (could it helps the compiler to manage the alignment problem?)I think I will send the v3 of my series without fixing that because I don't have enough time this week. I will address the problem later.No problem! I will also try to spend a moment and see if there's some reasonable solution I can suggest. Thanks,* to use C macrosI'm not sure exactly how, I have some vague idea of what you might mean, it could be quite awkward though.* to use these new functions only with vhost-user as we know pointers will be aligned.This is quite unlikely to help: the problem is that 802.3 (Ethernet) frame headers are (without VLANs) 14 bytes. If you align the start of the frame, and we need those frames (and pointers to them) whenever we talk Layer-2, the rest can't be aligned to 4-bytes boundary.* to include structure we want to address in a generic wrapperstructure that will unalign it as it is done with the current structure.This sounds like the easiest and safest way to me. Note that pointers to 'taph' can be happily dereferenced, too. You can pass around pointers to that, instead of using 'iph'. I used (almost everywhere?) the start of the buffer, but 'taph' is fine as well. -- Stefano