On Fri, 18 Mar 2016 14:49:57 +0100 Thomas Monjalon <thomas.monjalon at 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 at 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
