From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wes1-so2.wedos.net (wes1-so2.wedos.net [46.28.106.16]) by dpdk.org (Postfix) with ESMTP id C06C2559C for ; Tue, 8 Dec 2015 21:53:17 +0100 (CET) Received: from jvn (dynamic-109-81-211-171.ipv4.broadband.iol.cz [109.81.211.171]) by wes1-so2.wedos.net (Postfix) with ESMTPSA id 3pFYcs2mKmzTB; Tue, 8 Dec 2015 21:53:17 +0100 (CET) Date: Tue, 8 Dec 2015 21:53:11 +0100 From: Jan Viktorin To: Stephen Hemminger Message-ID: <20151208215311.628a9b2f@jvn> In-Reply-To: <20151208120254.45758054@xeon-e3> References: <1449602993-6047-1-git-send-email-viktorin@rehivetech.com> <20151208120254.45758054@xeon-e3> Organization: RehiveTech X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [[RFC PATCH]] lib/ether: fix 16-bit unaligned access X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 20:53:17 -0000 On Tue, 8 Dec 2015 12:02:54 -0800 Stephen Hemminger wrote: > On Tue, 8 Dec 2015 20:29:53 +0100 > Jan Viktorin wrote: > > > Hello, > > > > I was looking at some warnings generated during ARM build. I can see > > 53 warnings for my build based on v2.2.0-rc3, spread among: > > > > app/test-pmd/{flowgen,icmpecho,txonly}.c > > app/test/{packet_burst_generator,test_hash_functions,test_thash}.c > > lib/librte_ether/rte_ether.h > > drivers/net/bonding/rte_eth_bond_pmd.c > > lib/librte_acl/{acl_gen,acl_run}.c > > lib/librte_eal/linuxapp/eal/{eal_interrupts,eal_pci_vfio_mp_sync}.c > > lib/librte_hash/rte_cuckoo_hash.c > > lib/librte_ip_frag/rte_ipv4_reassembly.c > > lib/librte_sched/{rte_bitmap.h,rte_sched.c} > > > > I think, some of them are false-positives. In this RFC patch I tried to fix > > only the rte_ether.h which uses the unaligned_uint16_t data type. I didn't > > test it as it is just the first kick to solve more of those warns. > > > > Regards > > Jan > > > > (I considered to not add the cover-letter as this is just a single small patch. > > I hope it does not matter a lot. Is there any convention how to do this?) > > --- > > This commit removes warning reported when building for ARMv7 target. > > > > Signed-off-by: Jan Viktorin > > --- > > lib/librte_ether/rte_ether.h | 5 ++--- > > 1 file changed, 2 insertions(+), 3 deletions(-) > > > > diff --git a/lib/librte_ether/rte_ether.h b/lib/librte_ether/rte_ether.h > > index 07c17d7..ba8a80a 100644 > > --- a/lib/librte_ether/rte_ether.h > > +++ b/lib/librte_ether/rte_ether.h > > @@ -175,10 +175,9 @@ static inline int is_multicast_ether_addr(const struct ether_addr *ea) > > */ > > static inline int is_broadcast_ether_addr(const struct ether_addr *ea) > > { > > - const unaligned_uint16_t *ea_words = (const unaligned_uint16_t *)ea; > > + const uint32_t *ea_words = (const uint32_t *)ea; > > > > - return (ea_words[0] == 0xFFFF && ea_words[1] == 0xFFFF && > > - ea_words[2] == 0xFFFF); > > + return ea_words[0] == 0xFFFFFFFF && (ea_words[1] & 0x0FFFF) == 0x0FFFF; > > The problem with that is that it assumes little-endian. Well, true. But there is another issue that I considered just after left for home today :). The ether_addr can be unaligned in memory easily (as it comes in the Ethernet frame). Another false-positive... So the original code is correct. The fix would be to mute the compiler here. The solution is probably to enable RTE_ARCH_STRICT_ALIGN in the defconfig_arm-armv7a-linuxapp-gcc. This will probably solve more unaligned false-positives. Regards Jan -- Jan Viktorin E-mail: Viktorin@RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic