RE: [PATCH v2 08/10] hash: fix unaligned access in predictable RSS

[Konstantin Ananyev <konstantin.ananyev@huawei.com>]

> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Tuesday, July 15, 2025 12:57 PM
> To: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> Cc: dev@dpdk.org; stable@dpdk.org; Yipeng Wang <yipeng1.wang@intel.com>; Sameh Gobriel <sameh.gobriel@intel.com>; Bruce
> Richardson <bruce.richardson@intel.com>; Vladimir Medvedkin <vladimir.medvedkin@intel.com>; John McNamara
> <john.mcnamara@intel.com>
> Subject: Re: [PATCH v2 08/10] hash: fix unaligned access in predictable RSS
> 
> On Tue, Jul 8, 2025 at 7:58 PM Konstantin Ananyev
> <konstantin.ananyev@huawei.com> wrote:
> > > > Just wonder do you guys consider it as a real one?
> > > > AFAIK, all architectures that we care about do support unaligned load for 32-bit integers.
> > >
> > > Well this is undefined behavior, regardless of what the architecture support.
> > > And the compiler may end up generating wrong code.
> >
> > Probably, though AFAIK, we do have a lot of code that load 32-bit values from possibly
> > non-aligned addresses (nearly all packet parsing does that).
> > I wonder why it only complained only about that one?
> 
> Probably because unit tests coverage is (too) small.
> 
> 
> > BTW, would our 'unaligned_uint32_t' type help here?
> 
> Since most DPDK code rely on aligned types, using an unaligned type
> can work if we have a function that serves as a conversion from
> unaligned to aligned types.
> In this code, since the next operation is a byte swap operation on
> 32bits, I don't think we have many option but to memcpy().

[] For clarity, I am talking about something like that:
https://godbolt.org/z/vv6qzPMTz