[PATCH v2 0/5] eal: RTE_PTR_ADD qualifiers and real unaligned types

[Morten Brørup]

+TO: RING maintainers
+CC: Bruce, you might be able to recall something

> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Sunday, 6 September 2026 19.10
> 
> This series started with Scott Mitchell's patch to preserve pointer
> qualifications across RTE_PTR_ADD and RTE_PTR_SUB. Reviewing it
> turned up two further problems.
> 
> The first is that unaligned_uintNN_t only had alignment 1 on armv8
> aarch32, the one target setting RTE_ARCH_STRICT_ALIGN. Everywhere
> else they were ordinary aligned types, so code using them to read
> or write at arbitrary offsets was still undefined behaviour and was
> reported by UBSAN. Giving them alignment 1 on all architectures
> fixes that, and once mlx5 no longer needs its strict alignment
> path, RTE_ARCH_STRICT_ALIGN has no users left and is removed.
> 
> The second is the jhash test, which declared its key as a byte
> array and cast it to unaligned_uint32_t * to pass to a function
> taking const uint32_t *. That is fixed first in the series so the
> alignment change does not introduce a new clang warning.
> 
> Only patch 1 should go to stable.
> 
> Note for reviewers: unaligned_uintNN_t is in an installed header,
> so applications embedding one of these types in a structure will
> see its layout change. That is called out in the release notes.
> 
> The types are also used in the hash key compare path
> (rte_cuckoo_hash.c, rte_cmp_generic.h) and for 8 byte ring elements
> (rte_ring_elem_pvt.h). Scalar code generation is unchanged on x86,
> but the compiler can no longer assume alignment when combining
> adjacent accesses, so hash and ring perf results would be welcome,
> particularly on arm.

Is there a real reason why rings support unaligned objects?
Or was the "unaligned" just slapped on due to some old habit, like packing structs?

If there's no good reason, let's converge towards normal alignment in the ring library.

-Morten