On Tue, Jul 02, 2019 at 03:12:40PM -0700, Stephen Hemminger wrote:
> From: Bruce Richardson <bruce.richard...@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.richard...@intel.com>
> Signed-off-by: Stephen Hemminger <step...@networkplumber.org>
> Reviewed-by: Andrew Rybchenko <arybche...@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
