From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wes1-so1.wedos.net (wes1-so1.wedos.net [46.28.106.15]) by dpdk.org (Postfix) with ESMTP id 768072E8F for ; Fri, 18 Mar 2016 13:50:30 +0100 (CET) Received: from pcviktorin.fit.vutbr.cz (pcviktorin.fit.vutbr.cz [147.229.13.147]) by wes1-so1.wedos.net (Postfix) with ESMTPSA id 3qRQ7B1qgdzBqV; Fri, 18 Mar 2016 13:50:30 +0100 (CET) Date: Fri, 18 Mar 2016 13:50:36 +0100 From: Jan Viktorin To: "Kulasek, TomaszX" Cc: Thomas Monjalon , Jerin Jacob , "dev@dpdk.org" , "jianbo.liu@linaro.org" Message-ID: <20160318135036.631fa60a@pcviktorin.fit.vutbr.cz> In-Reply-To: <3042915272161B4EB253DA4D77EB373A14E6C71E@IRSMSX102.ger.corp.intel.com> References: <1458293807-2604-1-git-send-email-tomaszx.kulasek@intel.com> <1902439.xcempkFplY@xps13> <20160318105158.GA13693@localhost.localdomain> <1734050.PspUeD4iGQ@xps13> <20160318125650.7469a086@pcviktorin.fit.vutbr.cz> <3042915272161B4EB253DA4D77EB373A14E6C71E@IRSMSX102.ger.corp.intel.com> Organization: RehiveTech MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v5] examples/l3fwd: em path performance fix 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: Fri, 18 Mar 2016 12:50:30 -0000 On Fri, 18 Mar 2016 12:45:03 +0000 "Kulasek, TomaszX" wrote: > > -----Original Message----- > > From: Jan Viktorin [mailto:viktorin@rehivetech.com] > > Sent: Friday, March 18, 2016 12:57 > > To: Thomas Monjalon > > Cc: Jerin Jacob ; Kulasek, TomaszX > > ; dev@dpdk.org; jianbo.liu@linaro.org > > Subject: Re: [dpdk-dev] [PATCH v5] examples/l3fwd: em path performance fix > > > > Hello Thomas, Jerin, Tomasz, all... > > > > On Fri, 18 Mar 2016 12:00:24 +0100 > > Thomas Monjalon wrote: > > > > > 2016-03-18 16:22, Jerin Jacob: > > > > On Fri, Mar 18, 2016 at 11:04:49AM +0100, Thomas Monjalon wrote: > > > > > 2016-03-18 10:52, Tomasz Kulasek: > > > > > > +#if !defined(NO_HASH_MULTI_LOOKUP) && defined(__ARM_NEON) > > > > > > > > > > I think we should use CONFIG_RTE_ARCH_ARM_NEON here. > > > > > Any ARM maintainer to confirm? > > > > > > > > __ARM_NEON should work existing GCC, but it is better to use > > > > RTE_MACHINE_CPUFLAG_NEON as -it has been generated by probing the > > > > compiler capabilities. > > > > -it's future-proof solution to support clang or other gcc versions > > > > in future > > > > > > I agree to use RTE_MACHINE_CPUFLAG_NEON. > > > > > > I just don't understand why CONFIG_RTE_ARCH_ARM_NEON has been > > introduced. > > > It seems to be used to disable NEON on ARMv7: > > > > This is true. You should be able to disable the NEON-specific code if it > > is unwanted. Eg., the memcpy operations are not always faster with NEON. > > But... > > > > $ git grep ARM_NEON > > ... > > lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h:45:#ifdef > > __ARM_NEON_FP > > lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h:328:#endif /* > > __ARM_NEON_FP */ ... > > > > From this point of view, this is wrong and should be fixed to check a > > different constant. > > > > > ifeq ($(CONFIG_RTE_ARCH_ARM_NEON),y) > > > MACHINE_CFLAGS += -mfpu=neon > > > endif > > > > However, there is another possible way of understanding these options. > > We can (well, unlikely and I am about to say 'never') have an ARM > > processor without NEON. This cannot be detected by gcc as it does not know > > the target processor... So from my point of view: > > > > * CONFIG_RTE_ARCH_ARM_NEON says "my CPU does (not) support NEON" or "I > > want to enable/disable NEON" while > > * RTE_MACHINE_CPUFLAG_NEON says, the _compiler_ supports NEON > > > > I'll send a patch trying to solve this. > > > > Regards > > Jan > > Hi > > As I understand with your last patch it's safe and preferred to use RTE_MACHINE_CPUFLAG_NEON for ARM Neon detection? If so, I can include this modification for whole l3fwd in v6 of this patch. Yes, I'd prefer this approach as well. Jan > > Tomasz. -- Jan Viktorin E-mail: Viktorin@RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic