> -----Original Message----- > From: Jan Viktorin [mailto:viktorin at rehivetech.com] > Sent: Friday, March 18, 2016 12:57 > To: Thomas Monjalon <thomas.monjalon at 6wind.com> > Cc: Jerin Jacob <jerin.jacob at caviumnetworks.com>; Kulasek, TomaszX > <tomaszx.kulasek at intel.com>; dev at dpdk.org; jianbo.liu at 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 <thomas.monjalon at 6wind.com> 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. Tomasz.
