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 */ ...
