From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <viktorin@rehivetech.com>
Received: from wes1-so2.wedos.net (wes1-so2.wedos.net [46.28.106.16])
 by dpdk.org (Postfix) with ESMTP id E22DF5938
 for <dev@dpdk.org>; Fri, 18 Mar 2016 12:56:44 +0100 (CET)
Received: from pcviktorin.fit.vutbr.cz (pcviktorin.fit.vutbr.cz
 [147.229.13.147])
 by wes1-so2.wedos.net (Postfix) with ESMTPSA id 3qRNx84XC4z8rf;
 Fri, 18 Mar 2016 12:56:44 +0100 (CET)
Date: Fri, 18 Mar 2016 12:56:50 +0100
From: Jan Viktorin <viktorin@rehivetech.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: Jerin Jacob <jerin.jacob@caviumnetworks.com>, Tomasz Kulasek
 <tomaszx.kulasek@intel.com>, dev@dpdk.org, jianbo.liu@linaro.org
Message-ID: <20160318125650.7469a086@pcviktorin.fit.vutbr.cz>
In-Reply-To: <1734050.PspUeD4iGQ@xps13>
References: <1458293807-2604-1-git-send-email-tomaszx.kulasek@intel.com>
 <1902439.xcempkFplY@xps13>
 <20160318105158.GA13693@localhost.localdomain>
 <1734050.PspUeD4iGQ@xps13>
Organization: RehiveTech
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Subject: Re: [dpdk-dev] [PATCH v5] examples/l3fwd: em path performance fix
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Mar 2016 11:56:45 -0000

Hello Thomas, Jerin, Tomasz, all...

On Fri, 18 Mar 2016 12:00:24 +0100
Thomas Monjalon <thomas.monjalon@6wind.com> wrote:

> 2016-03-18 16:22, Jerin Jacob:
> > On Fri, Mar 18, 2016 at 11:04:49AM +0100, Thomas Monjalon wrote: =20
> > > 2016-03-18 10:52, Tomasz Kulasek: =20
> > > > +#if !defined(NO_HASH_MULTI_LOOKUP) && defined(__ARM_NEON) =20
> > >=20
> > > I think we should use CONFIG_RTE_ARCH_ARM_NEON here.
> > > Any ARM maintainer to confirm? =20
> >=20
> > __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 =20
>=20
> I agree to use RTE_MACHINE_CPUFLAG_NEON.
>=20
> 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 */
...

=46rom this point of view, this is wrong and should be fixed to check
a different constant.

> 	ifeq ($(CONFIG_RTE_ARCH_ARM_NEON),y)                                    =
                                        =20
> 	MACHINE_CFLAGS +=3D -mfpu=3Dneon
> 	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