From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Subject: Re: [PATCH 2/3] arm64: acl: add neon based acl
	implementation
Date: Tue, 3 Nov 2015 10:00:55 +0530
Message-ID: <20151103043051.GA2228@localhost.localdomain>
References: <1446473921-12706-1-git-send-email-jerin.jacob@caviumnetworks.com>
 <1446473921-12706-2-git-send-email-jerin.jacob@caviumnetworks.com>
 <1446473921-12706-3-git-send-email-jerin.jacob@caviumnetworks.com>
 <2601191342CEEE43887BDE71AB97725836AB86A5@irsmsx105.ger.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: "dev@dpdk.org" <dev@dpdk.org>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from na01-bl2-obe.outbound.protection.outlook.com
 (mail-bl2on0057.outbound.protection.outlook.com [65.55.169.57])
 by dpdk.org (Postfix) with ESMTP id AF6448E9E
 for <dev@dpdk.org>; Tue,  3 Nov 2015 05:31:21 +0100 (CET)
Content-Disposition: inline
In-Reply-To: <2601191342CEEE43887BDE71AB97725836AB86A5@irsmsx105.ger.corp.intel.com>
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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Mon, Nov 02, 2015 at 04:54:24PM +0000, Ananyev, Konstantin wrote:
> Hi Jacob,
> 
> > diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
> > index d60219f..e2fdebd 100644
> > --- a/lib/librte_acl/rte_acl.c
> > +++ b/lib/librte_acl/rte_acl.c
> > @@ -55,11 +55,32 @@ rte_acl_classify_avx2(__rte_unused const struct rte_acl_ctx *ctx,
> >  	return -ENOTSUP;
> >  }
> > 
> > +int __attribute__ ((weak))
> > +rte_acl_classify_sse(__rte_unused const struct rte_acl_ctx *ctx,
> > +	__rte_unused const uint8_t **data,
> > +	__rte_unused uint32_t *results,
> > +	__rte_unused uint32_t num,
> > +	__rte_unused uint32_t categories)
> > +{
> > +	return -ENOTSUP;
> > +}
> > +
> > +int __attribute__ ((weak))
> > +rte_acl_classify_neon(__rte_unused const struct rte_acl_ctx *ctx,
> > +	__rte_unused const uint8_t **data,
> > +	__rte_unused uint32_t *results,
> > +	__rte_unused uint32_t num,
> > +	__rte_unused uint32_t categories)
> > +{
> > +	return -ENOTSUP;
> > +}
> > +
> >  static const rte_acl_classify_t classify_fns[] = {
> >  	[RTE_ACL_CLASSIFY_DEFAULT] = rte_acl_classify_scalar,
> >  	[RTE_ACL_CLASSIFY_SCALAR] = rte_acl_classify_scalar,
> >  	[RTE_ACL_CLASSIFY_SSE] = rte_acl_classify_sse,
> >  	[RTE_ACL_CLASSIFY_AVX2] = rte_acl_classify_avx2,
> > +	[RTE_ACL_CLASSIFY_NEON] = rte_acl_classify_neon,
> >  };
> > 
> >  /* by default, use always available scalar code path. */
> > @@ -93,6 +114,9 @@ rte_acl_init(void)
> >  {
> >  	enum rte_acl_classify_alg alg = RTE_ACL_CLASSIFY_DEFAULT;
> > 
> > +#ifdef RTE_ARCH_ARM64
> > +	alg =  RTE_ACL_CLASSIFY_NEON;
> > +#else

Hi Konstantin,
> 
> On ARM, is there any specific cpu flag that you can use to determine is NEON
> isa is supported or not?

Yes, on armv7(RTE_CPUFLAG_NEON). On armv8-a NEON is mandatory.

> It would be good to avoid extra conditional compilation here if possible.
neon acl is verified/ported only on armv8. While adding the armv7 support the
check can be extended for cpuflag based on RTE_CPUFLAG_NEON on armv7

> Another question - did I get it right that NEON isa is supported on all
> possible RTE_ARCH_ARM64 cpu models you plan to support?

Yes

> Konstantin
> 
>