From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0049.outbound.protection.outlook.com [104.47.37.49]) by dpdk.org (Postfix) with ESMTP id 4F07B2935 for ; Fri, 28 Apr 2017 12:38:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=J7FUQiDzHXyOcsTeLOKY6nttHdgmvmzE3wwneJFUSyw=; b=gj8ZPnxaJjYR/gEI6ibjnp0hmJ4q5W//Chw7k8g+O+JZ1QQuVzv7+zaDVW+0lODVjXSc7LjIygmz7m1ARjyDmzNgWdGZfGMi3IznOQQz/8jNvCmzeQgVwwFRlep8uknG3lgQ/wiYz90LkeKYCjwNEzi1FFZ8olO3cAur+d9tRLw= Received: from BY2PR07MB2421.namprd07.prod.outlook.com (10.166.115.13) by CY1PR0701MB1728.namprd07.prod.outlook.com (10.163.21.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Fri, 28 Apr 2017 10:38:04 +0000 Received: from BY2PR07MB2421.namprd07.prod.outlook.com ([10.166.115.13]) by BY2PR07MB2421.namprd07.prod.outlook.com ([10.166.115.13]) with mapi id 15.01.1061.016; Fri, 28 Apr 2017 10:38:02 +0000 From: "Sekhar, Ashwin" To: Jianbo Liu CC: "byron.marohn@intel.com" , "pablo.de.lara.guarch@intel.com" , "Jacob, Jerin" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v2] efd: support lookup using neon intrinsics Thread-Index: AQHSv1QECWt4uIwewUObPZduoNgi/A== Date: Fri, 28 Apr 2017 10:38:02 +0000 Message-ID: References: <20170427114249.31863-1-ashwin.sekhar@caviumnetworks.com> <20170427124418.32857-1-ashwin.sekhar@caviumnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: linaro.org; dkim=none (message not signed) header.d=none;linaro.org; dmarc=none action=none header.from=cavium.com; x-originating-ip: [111.93.218.67] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR0701MB1728; 7:Xx/8jtviwZWDcxvmb2DSM5BOWPkMd1P3+6oOA1n8xal8HxAAWNqs9Xz1nk/ZQRyIKnKek/aNP0nqSPDEmchSCrD4owlkWk+9h+oBlv2OWgdgiSHoHbFyBY/tdzw8nMNeoyGEbetQV9z2KmEd4s0INstlbEE9DvRHfXKGy3IUxednctz4wMukLMToiKLBbIYmrZ5ng+OR7BkI0MrbnpbvwE/+Bx6xuIIMpzn9yO6s9MzKQwbH3qnYR7RX9I+UI/Mvtkt/rTZJl373QO6s7bp0wGRpv6CLz3C69lvUEqvNN2KsuKBmieSEmvnISqSEmu6XosleG8tm+7jel1uYACtd8A== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39410400002)(39400400002)(39850400002)(377454003)(24454002)(5660300001)(2900100001)(33656002)(74316002)(305945005)(3280700002)(3660700001)(6916009)(7736002)(50986999)(76176999)(54356999)(229853002)(3846002)(102836003)(6116002)(7696004)(66066001)(6506006)(53936002)(4326008)(6436002)(8936002)(2906002)(81166006)(8676002)(122556002)(86362001)(6246003)(77096006)(189998001)(9686003)(55016002)(38730400002)(54906002)(99286003)(110136004)(53546009)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0701MB1728; H:BY2PR07MB2421.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 9b6075a3-5e78-41a0-079c-08d48e22a5e5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:CY1PR0701MB1728; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:CY1PR0701MB1728; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1728; x-forefront-prvs: 029174C036 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: cavium.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2017 10:38:02.7958 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1728 Subject: Re: [dpdk-dev] [PATCH v2] efd: support lookup using neon intrinsics X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 10:38:06 -0000 On Friday 28 April 2017 03:36 PM, Jianbo Liu wrote:=0A= > On 27 April 2017 at 20:44, Ashwin Sekhar T K=0A= > wrote:=0A= >> * Added file lib/librte_efd/rte_efd_arm64.h to hold arm64=0A= >> specific definitions=0A= >> * Verified the changes with efd_autotest unit test case=0A= >>=0A= >> Signed-off-by: Ashwin Sekhar T K =0A= >> ---=0A= >> v2:=0A= >> * Slightly modified the content of the commit message body=0A= >> * Added prefix [dpdk-dev] to the email subject line=0A= >>=0A= >> MAINTAINERS | 1 +=0A= >> lib/librte_efd/rte_efd.c | 22 ++++++++++++=0A= >> lib/librte_efd/rte_efd_arm64.h | 76 +++++++++++++++++++++++++++++++++++= +++++++=0A= >> 3 files changed, 99 insertions(+)=0A= >> create mode 100644 lib/librte_efd/rte_efd_arm64.h=0A= >>=0A= >> diff --git a/MAINTAINERS b/MAINTAINERS=0A= >> index b6495d2..7d708ae 100644=0A= >> --- a/MAINTAINERS=0A= >> +++ b/MAINTAINERS=0A= >> @@ -147,6 +147,7 @@ F: lib/librte_eal/common/include/arch/arm/*_64.h=0A= >> F: lib/librte_acl/acl_run_neon.*=0A= >> F: lib/librte_lpm/rte_lpm_neon.h=0A= >> F: lib/librte_hash/rte*_arm64.h=0A= >> +F: lib/librte_efd/rte*_arm64.h=0A= >> F: drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c=0A= >> F: drivers/net/i40e/i40e_rxtx_vec_neon.c=0A= >> F: drivers/net/virtio/virtio_rxtx_simple_neon.c=0A= >> diff --git a/lib/librte_efd/rte_efd.c b/lib/librte_efd/rte_efd.c=0A= >> index f601d62..4d9a088 100644=0A= >> --- a/lib/librte_efd/rte_efd.c=0A= >> +++ b/lib/librte_efd/rte_efd.c=0A= >> @@ -53,6 +53,8 @@=0A= >> #include "rte_efd.h"=0A= >> #if defined(RTE_ARCH_X86)=0A= >> #include "rte_efd_x86.h"=0A= >> +#elif defined(RTE_ARCH_ARM64)=0A= >> +#include "rte_efd_arm64.h"=0A= >> #endif=0A= >>=0A= >> #define EFD_KEY(key_idx, table) (table->keys + ((key_idx) * table->key_= len))=0A= >> @@ -103,6 +105,7 @@ allocated memory=0A= >> enum efd_lookup_internal_function {=0A= >> EFD_LOOKUP_SCALAR =3D 0,=0A= >> EFD_LOOKUP_AVX2,=0A= >> + EFD_LOOKUP_NEON,=0A= >=0A= > Should it be included in "if defined(RTE_ARCH_ARM64)"?=0A= >=0A= The enum can be wrapped under "if defined(RTE_ARCH_ARM64)" with no =0A= issues, as all its usages are also under "if defined(RTE_ARCH_ARM64)".=0A= I followed EFD_LOOKUP_AVX2 and defined EFD_LOOKUP_NEON on the same lines.= =0A= Please advise on whether this change is to be made. Will follow your advice= .=0A= >> EFD_LOOKUP_NUM=0A= >> };=0A= >>=0A= >> @@ -674,6 +677,16 @@ rte_efd_create(const char *name, uint32_t max_num_r= ules, uint32_t key_len,=0A= >> table->lookup_fn =3D EFD_LOOKUP_AVX2;=0A= >> else=0A= >> #endif=0A= >> +#if defined(RTE_ARCH_ARM64)=0A= >> + /*=0A= >> + * For less than or equal to 16 bits, scalar function performs b= etter=0A= >> + * than vectorised version=0A= >> + */=0A= >> + if (RTE_EFD_VALUE_NUM_BITS > 16 &&=0A= >> + rte_cpu_get_flag_enabled(RTE_CPUFLAG_NEON))=0A= >> + table->lookup_fn =3D EFD_LOOKUP_NEON;=0A= >> + else=0A= >> +#endif=0A= >> table->lookup_fn =3D EFD_LOOKUP_SCALAR;=0A= >>=0A= >> /*=0A= >> @@ -1271,6 +1284,15 @@ efd_lookup_internal(const struct efd_online_group= _entry * const group,=0A= >> group->lookup_table,=0A= >> hash_val_a,=0A= >> hash_val_b);=0A= >> + break;=0A= >> +#endif=0A= >> +#if defined(RTE_ARCH_ARM64)=0A= >> + case EFD_LOOKUP_NEON:=0A= >> + return efd_lookup_internal_neon(group->hash_idx,=0A= >> + group->lookup_table,=0A= >> + hash_val_a,=0A= >> + hash_val_b);=0A= >> + break;=0A= >> #endif=0A= >> case EFD_LOOKUP_SCALAR:=0A= >> /* Fall-through */=0A= >> diff --git a/lib/librte_efd/rte_efd_arm64.h b/lib/librte_efd/rte_efd_arm= 64.h=0A= >> new file mode 100644=0A= >> index 0000000..cc93411=0A= >> --- /dev/null=0A= >> +++ b/lib/librte_efd/rte_efd_arm64.h=0A= >> @@ -0,0 +1,76 @@=0A= >> +/*=0A= >> + * BSD LICENSE=0A= >> + *=0A= >> + * Copyright (C) Cavium networks Ltd. 2017.=0A= >> + *=0A= >> + * Redistribution and use in source and binary forms, with or without= =0A= >> + * modification, are permitted provided that the following conditions= =0A= >> + * are met:=0A= >> + *=0A= >> + * * Redistributions of source code must retain the above copyright= =0A= >> + * notice, this list of conditions and the following disclaimer.= =0A= >> + * * Redistributions in binary form must reproduce the above copyri= ght=0A= >> + * notice, this list of conditions and the following disclaimer i= n=0A= >> + * the documentation and/or other materials provided with the=0A= >> + * distribution.=0A= >> + * * Neither the name of Cavium networks nor the names of its=0A= >> + * contributors may be used to endorse or promote products derive= d=0A= >> + * from this software without specific prior written permission.= =0A= >> + *=0A= >> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTOR= S=0A= >> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT= =0A= >> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS = FOR=0A= >> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIG= HT=0A= >> + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENT= AL,=0A= >> + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT= =0A= >> + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF U= SE,=0A= >> + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON = ANY=0A= >> + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TOR= T=0A= >> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE = USE=0A= >> + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAG= E.=0A= >> + */=0A= >> +=0A= >> +/*=0A= >> + * rte_efd_arm64.h=0A= >> + * This file holds all arm64 specific EFD functions=0A= >> + */=0A= >> +=0A= >> +#ifndef __RTE_EFD_ARM64_H__=0A= >> +#define __RTE_EFD_ARM64_H__=0A= >> +=0A= >> +#include =0A= >> +=0A= >> +static inline efd_value_t=0A= >> +efd_lookup_internal_neon(const efd_hashfunc_t *group_hash_idx,=0A= >> + const efd_lookuptbl_t *group_lookup_table,=0A= >> + const uint32_t hash_val_a, const uint32_t hash_val_b)=0A= >> +{=0A= >> + efd_value_t value =3D 0;=0A= >> + uint32_t i =3D 0;=0A= >> + uint32x4_t vhash_val_a =3D vmovq_n_u32(hash_val_a);=0A= >> + uint32x4_t vhash_val_b =3D vmovq_n_u32(hash_val_b);=0A= >> + int32x4_t vshift =3D {0, 1, 2, 3};=0A= >> + uint32x4_t vmask =3D vdupq_n_u32(0x1);=0A= >> + int32x4_t vincr =3D vdupq_n_s32(4);=0A= >> +=0A= >> + for (; i < RTE_EFD_VALUE_NUM_BITS; i +=3D 4) {=0A= >> + uint32x4_t vhash_idx =3D vshll_n_u16(=0A= >> + vld1_u16((uint16_t const *)&group_hash_idx[i]), = 0);=0A= >> + uint32x4_t vlookup_table =3D vshll_n_u16(=0A= >> + vld1_u16((uint16_t const *)&group_lookup_table[i= ]), 0);=0A= >> + uint32x4_t vhash =3D vaddq_u32(vhash_val_a,=0A= >> + vmulq_u32(vhash_idx, vhash_val_b= ));=0A= >> + int32x4_t vbucket_idx =3D vnegq_s32(vreinterpretq_s32_u3= 2(=0A= >> + vshrq_n_u32(vhash, EFD_LOOKUPTBL_SHIFT))= );=0A= >> + uint32x4_t vresult =3D vshlq_u32(vlookup_table, vbucket_= idx);=0A= >> +=0A= >> + vresult =3D vandq_u32(vresult, vmask);=0A= >> + vresult =3D vshlq_u32(vresult, vshift);=0A= >> + value |=3D vaddvq_u32(vresult);=0A= >> + vshift =3D vaddq_s32(vshift, vincr);=0A= >> + }=0A= >> +=0A= >> + return value;=0A= >> +}=0A= >> +=0A= >> +#endif /* __RTE_EFD_ARM64_H__ */=0A= >> --=0A= >> 2.7.4=0A= >>=0A= >=0A= =0A=