Re: [dpdk-dev] [PATCH v7 05/12] net/ether: mark ethernet addresses as being 2-byte aligned

[Olivier Matz <olivier.matz@6wind.com>]

On Tue, Jul 02, 2019 at 03:12:40PM -0700, Stephen Hemminger wrote:
> From: Bruce Richardson <bruce.richardson@intel.com>
> 
> When including the rte_ether.h header in applications with warnings
> enabled, a warning was given because of the assumption of 2-byte alignment
> of ethernet addresses when processing them.
> 
> .../include/rte_ether.h:149:2: warning: converting a packed ‘const
>   struct ether_addr’ pointer (alignment 1) to a ‘unaligned_uint16_t’
>   {aka ‘const short unsigned int’} pointer (alignment 2) may result in
>   an unaligned pointer value [-Waddress-of-packed-member]
> 149 |  const unaligned_uint16_t *ea_words = (const unaligned_uint16_t *)ea;
>     |  ^~~~~
> 
> Since ethernet addresses should always be aligned on a two-byte boundary,
> we can just inform the compiler of this assumption to remove the warnings
> and allow us to always access the addresses using 16-bit operations.
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
> ---
>  lib/librte_net/rte_ether.h | 11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h
> index feb35a33c94b..d7b76ddf63eb 100644
> --- a/lib/librte_net/rte_ether.h
> +++ b/lib/librte_net/rte_ether.h
> @@ -58,7 +58,8 @@ extern "C" {
>   * See http://standards.ieee.org/regauth/groupmac/tutorial.html
>   */
>  struct rte_ether_addr {
> -	uint8_t addr_bytes[RTE_ETHER_ADDR_LEN]; /**< Addr bytes in tx order */
> +	uint8_t addr_bytes[RTE_ETHER_ADDR_LEN] __rte_aligned(2);
> +	/**< Addr bytes in tx order */
>  } __attribute__((__packed__));
>  
>  #define RTE_ETHER_LOCAL_ADMIN_ADDR 0x02 /**< Locally assigned Eth. address. */
> @@ -81,8 +82,8 @@ struct rte_ether_addr {
>  static inline int rte_is_same_ether_addr(const struct rte_ether_addr *ea1,
>  				     const struct rte_ether_addr *ea2)
>  {
> -	const unaligned_uint16_t *w1 = (const uint16_t *)ea1;
> -	const unaligned_uint16_t *w2 = (const uint16_t *)ea2;
> +	const uint16_t *w1 = (const uint16_t *)ea1;
> +	const uint16_t *w2 = (const uint16_t *)ea2;
>  
>  	return ((w1[0] ^ w2[0]) | (w1[1] ^ w2[1]) | (w1[2] ^ w2[2])) == 0;
>  }
> @@ -99,7 +100,7 @@ static inline int rte_is_same_ether_addr(const struct rte_ether_addr *ea1,
>   */
>  static inline int rte_is_zero_ether_addr(const struct rte_ether_addr *ea)
>  {
> -	const unaligned_uint16_t *w = (const uint16_t *)ea;
> +	const uint16_t *w = (const uint16_t *)ea;
>  
>  	return (w[0] | w[1] | w[2]) == 0;
>  }
> @@ -146,7 +147,7 @@ static inline int rte_is_multicast_ether_addr(const struct rte_ether_addr *ea)
>   */
>  static inline int rte_is_broadcast_ether_addr(const struct rte_ether_addr *ea)
>  {
> -	const unaligned_uint16_t *ea_words = (const unaligned_uint16_t *)ea;
> +	const uint16_t *ea_words = (const uint16_t *)ea;
>  
>  	return (ea_words[0] == 0xFFFF && ea_words[1] == 0xFFFF &&
>  		ea_words[2] == 0xFFFF);
> -- 
> 2.20.1
> 

Following this discussion:
https://mails.dpdk.org/archives/dev/2019-July/136590.html

I still think that changing the ABI without deprecation notice
is not a good idea.

The warning issued by the compiler makes me think that the definition of
unaligned_uint16_t is wrong on intel arch. I made a quick test, and it
seems that in this particular case, the generated code is the same with
or without __attribute__((aligned(1))). See: https://godbolt.org/z/NjBNQk

But changing the definition of unaligned_uint16_t without a deprecation
notice is not an option either.

What do you think about using a specific typedef similar to
unaligned_uint16_t in rte_ether, that has the __attribute__((aligned(1))) ?
It would avoid to change the alignment of struct rte_ether_addr.

In parallel, we can talk about changing unaligned_uint16_t for intel
in another patchset.

Olivier