> -----Original Message----- > From: David Marchand <[email protected]> > Sent: Tuesday, July 15, 2025 12:57 PM > To: Konstantin Ananyev <[email protected]> > Cc: [email protected]; [email protected]; Yipeng Wang <[email protected]>; > Sameh Gobriel <[email protected]>; Bruce > Richardson <[email protected]>; Vladimir Medvedkin > <[email protected]>; John McNamara > <[email protected]> > Subject: Re: [PATCH v2 08/10] hash: fix unaligned access in predictable RSS > > On Tue, Jul 8, 2025 at 7:58 PM Konstantin Ananyev > <[email protected]> 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
