From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id E76E2569C for ; Fri, 18 Mar 2016 13:45:29 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP; 18 Mar 2016 05:45:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,355,1455004800"; d="scan'208";a="936779593" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by orsmga002.jf.intel.com with ESMTP; 18 Mar 2016 05:45:05 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.19]) by IRSMSX106.ger.corp.intel.com ([169.254.8.172]) with mapi id 14.03.0248.002; Fri, 18 Mar 2016 12:45:04 +0000 From: "Kulasek, TomaszX" To: Jan Viktorin , Thomas Monjalon CC: Jerin Jacob , "dev@dpdk.org" , "jianbo.liu@linaro.org" Thread-Topic: [dpdk-dev] [PATCH v5] examples/l3fwd: em path performance fix Thread-Index: AQHRgPweodPvUmS5s0maOlKhlbw3up9e+T6AgAANLwCAAAJYAIAAD8UAgAALWzA= Date: Fri, 18 Mar 2016 12:45:03 +0000 Message-ID: <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> In-Reply-To: <20160318125650.7469a086@pcviktorin.fit.vutbr.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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:45:30 -0000 > -----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 fi= x >=20 > Hello Thomas, Jerin, Tomasz, all... >=20 > On Fri, 18 Mar 2016 12:00:24 +0100 > Thomas Monjalon wrote: >=20 > > 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: >=20 > 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... >=20 > $ 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 */ ... >=20 > From this point of view, this is wrong and should be fixed to check a > different constant. >=20 > > ifeq ($(CONFIG_RTE_ARCH_ARM_NEON),y) > > MACHINE_CFLAGS +=3D -mfpu=3Dneon > > endif >=20 > 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 kno= w > the target processor... So from my point of view: >=20 > * 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 >=20 > I'll send a patch trying to solve this. >=20 > Regards > Jan Hi As I understand with your last patch it's safe and preferred to use RTE_MAC= HINE_CPUFLAG_NEON for ARM Neon detection? If so, I can include this modific= ation for whole l3fwd in v6 of this patch. Tomasz.