Re: [dpdk-dev] [PATCH v3 4/4] eal/arm: introduce CONFIG_RTE_ARCH_ARM_NEON_MEMCPY

[Jerin Jacob <jerin.jacob@caviumnetworks.com>]

On Sun, Mar 20, 2016 at 11:29:48AM +0100, Thomas Monjalon wrote:
> 2016-03-20 10:41, Jan Viktorin:
> > On Sat, 19 Mar 2016 21:14:57 +0100
> > Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> > 
> > > 2016-03-19 20:58, Jan Viktorin:
> > > > The flag is used to enable memcpy optimizations in EAL. As it is not always
> > > > the performance benefit, the flag allows to disable it.  
> > > 
> > > Ideally the default should be to choose the best optimization.
> > > If it is not possible, it would help to have some comments explaining
> > > how to choose wether enabling NEON memcpy or not.
> > 
> > Ok, we can rename the option to CONFIG_RTE_ARCH_ARM_AVOID_NEON_MEMCPY,
> > delete it from the defconfig and change the test in rte_memcpy_32.h to
> > 
> > #ifndef CONFIG_RTE_ARCH_ARM_AVOID_NEON_MEMCPY
> > 
> > Alternatively, to have a positive test like
> > 
> > #ifdef CONFIG_RTE_ARCH_ARM_AVOID_NEON_MEMCPY
> > 
> > I can create a bigger change that moves the non-neon-memcpy up in the
> > file...
> > 
> > Should I resend the whole series as v3?
> 
> No, I don't think changing the name of the config or moving code
> will change anything.
> We just need to understand when it must be enabled or disabled.

By default, NEON implementation should be enabled in default config file,
if a given arm target/cpu has issue with NEON specific implementation
at target/cpu config level it can be disabled. IMO, Its inline with Jan's Patch.

The factors like NEON instruction execution cycles and pipelines
supported etc highly depend on the ARM target vendor implementation.
(ie arm specification does not mandate those fine-grained details)
so let target/cpu configuration decides any expectation is required or
not.

Jerin