> -----Original Message----- > From: David Marchand <david.march...@redhat.com> > Sent: Tuesday, July 15, 2025 12:57 PM > To: Konstantin Ananyev <konstantin.anan...@huawei.com> > Cc: dev@dpdk.org; sta...@dpdk.org; Yipeng Wang <yipeng1.w...@intel.com>; > Sameh Gobriel <sameh.gobr...@intel.com>; Bruce > Richardson <bruce.richard...@intel.com>; Vladimir Medvedkin > <vladimir.medved...@intel.com>; John McNamara > <john.mcnam...@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.anan...@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
