[dpdk-dev] arm: detect NEON by RTE_MACHINE_CPUFLAG_NEON flag only

  The RTE_MACHINE_CPUFLAG_NEON was only a result of the gcc testing.
However, the target CPU may not support NEON or the user can disable to
use it (as it does not always improve the performance).

The RTE_MACHINE_CPUFLAG_NEON detection is now based on both, the
__ARM_NEON_FP feature from gcc and CONFIG_RTE_ARCH_ARM_NEON from
the .config. The memcpy implemention is driven by
RTE_MACHINE_CPUFLAG_NEON, so the reason to disable neon is hidden for
the actual code.

Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
---

I can also include this one:

examples/l3fwd/l3fwd_em.c:253:#elif defined(__ARM_NEON)

---
 lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h | 4 ++--
 mk/machine/armv7a/rte.vars.mk                          | 2 +-
 mk/rte.cpuflags.mk                                     | 2 ++
 3 files changed, 5 insertions(+), 3 deletions(-)
  

2016-03-18 13:00, Jan Viktorin:
> The RTE_MACHINE_CPUFLAG_NEON was only a result of the gcc testing.
> However, the target CPU may not support NEON or the user can disable to
> use it (as it does not always improve the performance).
> 
> The RTE_MACHINE_CPUFLAG_NEON detection is now based on both, the
> __ARM_NEON_FP feature from gcc and CONFIG_RTE_ARCH_ARM_NEON from
> the .config. The memcpy implemention is driven by
> RTE_MACHINE_CPUFLAG_NEON, so the reason to disable neon is hidden for
> the actual code.
> 
> Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
> ---
> 
> I can also include this one:
> 
> examples/l3fwd/l3fwd_em.c:253:#elif defined(__ARM_NEON)

Yes please.
I will set my patch as superseded.
  

On Fri, 18 Mar 2016 14:49:57 +0100
Thomas Monjalon <thomas.monjalon@6wind.com> wrote:

> 2016-03-18 13:00, Jan Viktorin:
> > The RTE_MACHINE_CPUFLAG_NEON was only a result of the gcc testing.
> > However, the target CPU may not support NEON or the user can disable to
> > use it (as it does not always improve the performance).
> > 
> > The RTE_MACHINE_CPUFLAG_NEON detection is now based on both, the
> > __ARM_NEON_FP feature from gcc and CONFIG_RTE_ARCH_ARM_NEON from
> > the .config. The memcpy implemention is driven by
> > RTE_MACHINE_CPUFLAG_NEON, so the reason to disable neon is hidden for
> > the actual code.
> > 
> > Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
> > ---
> > 
> > I can also include this one:
> > 
> > examples/l3fwd/l3fwd_em.c:253:#elif defined(__ARM_NEON)  
> 
> Yes please.
> I will set my patch as superseded.
> 

OK, I will send v2.

By the way, for Intel-related code, it is also common to check eg.
__SSE2__ instead of the RTE_MACHINE_CPUFLAG_SSE2. That's probably a
source of confusion for new code, newcomers and adding new platforms.

As for me, I've had known about the CPUFLAGs... But I could hardly see
those in the DPDK code. It looks like the features are detected by
unused... And IMHO this is the reason why we are confused here.

Regards
Jan