> -----Original Message----- > From: Olivier Matz [mailto:olivier.m...@6wind.com] > Sent: Friday, July 5, 2019 3:34 PM > To: Stephen Hemminger <step...@networkplumber.org> > Cc: dev@dpdk.org; Richardson, Bruce <bruce.richard...@intel.com>; Andrew > Rybchenko <arybche...@solarflare.com> > Subject: Re: [dpdk-dev] [PATCH v7 05/12] net/ether: mark ethernet > addresses as being 2-byte aligned > > 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. > I'm ok with that. Let's put in a deprecation notice and take this patch in 19.11.
> 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. > I'd like the alignment changed. Since the existing warnings about alignment don’t seem to be causing anyone any real problems, I suggest we just leave them for now and fix them by changing the alignment setting for 19.11. > In parallel, we can talk about changing unaligned_uint16_t for intel > in another patchset. > Yes, let's fix the broken unaligned definition as a separate issue. /Bruce
