+ARM, RISC-V, LoongArch maintainers > From: Stephen Hemminger [mailto:[email protected]] > Sent: Saturday, 5 September 2026 00.09 > > The transmit inline copy splits the 8 byte case into two 32 bit > moves when RTE_ARCH_STRICT_ALIGN is set. Only armv8 aarch32 ever > set that flag, and ARMv8 does unaligned access in hardware, so the > split gains nothing. Use a single 64 bit move. > > The destination is inline_data, at offset 4 of a 16 byte aligned > dseg, so the 8 byte store is always misaligned. Write it through > the unaligned type; a plain uint64_t store there is undefined > behaviour and is reported by UBSAN. > > The debug assertion on the inline data offset goes away with the > strict alignment path since the wider move has no such requirement. > > Signed-off-by: Stephen Hemminger <[email protected]> > --- > drivers/net/mlx5/mlx5_tx.h | 12 +----------- > 1 file changed, 1 insertion(+), 11 deletions(-) > > diff --git a/drivers/net/mlx5/mlx5_tx.h b/drivers/net/mlx5/mlx5_tx.h > index 682dc07718..69a18f8a49 100644 > --- a/drivers/net/mlx5/mlx5_tx.h > +++ b/drivers/net/mlx5/mlx5_tx.h > @@ -1437,19 +1437,9 @@ mlx5_tx_dseg_iptr(struct mlx5_txq_data > *__rte_restrict txq, > dst = (uintptr_t)&dseg->inline_data[0]; > src = (uintptr_t)buf; > if (len & 0x08) { > -#ifdef RTE_ARCH_STRICT_ALIGN > - MLX5_ASSERT(dst == RTE_PTR_ALIGN(dst, sizeof(uint32_t))); > - *(uint32_t *)dst = *(unaligned_uint32_t *)src; > - dst += sizeof(uint32_t); > - src += sizeof(uint32_t); > - *(uint32_t *)dst = *(unaligned_uint32_t *)src; > - dst += sizeof(uint32_t); > - src += sizeof(uint32_t); > -#else > - *(uint64_t *)dst = *(unaligned_uint64_t *)src; > + *(unaligned_uint64_t *)dst = *(unaligned_uint64_t *)src; > dst += sizeof(uint64_t); > src += sizeof(uint64_t); > -#endif > } > if (len & 0x04) { > *(uint32_t *)dst = *(unaligned_uint32_t *)src; > -- > 2.53.0
This RFC series is an interesting idea! I'm in favor of eliminating RTE_ARCH_STRICT_ALIGN and #ifdefs like the one in this patch; it makes the code cleaner. And if we want to provide means for performance optimized code for architectures where alignment matter, we could introduce an "aligned4_uint64_t" type in addition to the "unaligned_uint64_t" type: https://godbolt.org/z/Ts4jhcdoW I'm not aware of the actual performance benefit such a new type would provide. BTW: The names could be shorter, e.g. "uint64u_t" or "uint64a1_t" instead of "unaligned_uint64_t" for the unaligned type, and "uint64a4_t" for the 4-byte aligned type. -Morten
