[RFC 2/3] net/mlx5: drop unnecessary STRICT_ALIGN

[Morten Brørup]

+ARM, RISC-V, LoongArch maintainers

> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> 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 <stephen at networkplumber.org>
> ---
>  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