> > > -----Original Message----- > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen Hemminger > > > Sent: Wednesday, June 5, 2019 7:10 PM > > > To: dev@dpdk.org > > > Cc: Richardson, Bruce <bruce.richard...@intel.com>; Stephen Hemminger > > > <step...@networkplumber.org>; Andrew Rybchenko > > > <arybche...@solarflare.com> > > > Subject: [dpdk-dev] [PATCH v4 5/8] net/ether: mark ethernet addresses > > > as being 2-byte aligned > > > > > > 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__)); > > > > Hmm, that would change layout of any struct/union that has struct > > rte_ether_addr inside. > > So seems like implicit ABI breakage to me. > > Konstantin > > > > I suppose it could, though only if you had the structure starting at an odd > byte > inside the larger structure.
Yes. > Personally, I'd think it should be ok in just about > all cases, as I'd find it hard to imagine when you wouldn't have this, but > technically I suppose it's a break. I also don't expect it to be a common case, but it is not totally impossible. So I still think it qualifies as ABI change and we need to follow our own ABI breakage policy here. > For real packet heads the fields will always be > two-byte aligned so there is no issue. >
