From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0099.outbound.protection.outlook.com [65.55.169.99]) by dpdk.org (Postfix) with ESMTP id 12A828DB4 for ; Wed, 2 Dec 2015 09:03:31 +0100 (CET) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@caviumnetworks.com; Received: from localhost.localdomain (122.167.201.210) by BLUPR0701MB1715.namprd07.prod.outlook.com (10.163.85.141) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 2 Dec 2015 08:03:25 +0000 Date: Wed, 2 Dec 2015 13:33:03 +0530 From: Jerin Jacob To: Jianbo Liu Message-ID: <20151202080259.GA32494@localhost.localdomain> References: <1448995276-9599-1-git-send-email-jianbo.liu@linaro.org> <1448995276-9599-4-git-send-email-jianbo.liu@linaro.org> <20151201164139.GA12144@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [122.167.201.210] X-ClientProxiedBy: PN1PR01CA0013.INDPRD01.PROD.OUTLOOK.COM (25.164.137.20) To BLUPR0701MB1715.namprd07.prod.outlook.com (25.163.85.141) X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1715; 2:oGpGXit5TAnqx9NZfGBmK5KR5BoZVbS3p3YVuLwVEYqYakPVEdfqFtYWB61J/iC008uaiNK0fQtW8rTliXCkXvMlFatGiYdFYvzAB1nXFn46EKDm2Awz97Dv6nxSSVf1fwWk9ZfWzMOPFay+y6Va1w==; 3:odmWb9/kXdHZpbkSarb36XA9+zlgEaLT67BqOdoG7yldRZHfHe2iNTCKpOeNfT27cv96opoNrKknPMMWCu3QnnHhZQsMSpqnc7MiChDbcA5eIjoDlMfekT3z+AEMtZNW; 25:J9lMSpwRnUq0EJ1i1fu0aH8WMfrtAMuLbWk+3aIpahxZ3XtKywlGT76oFAKVp98rRJIaDDQnZ78qPUiDoaMOu1pXkWXXpgTvEx8uYv1EhNGUbrKVyfFhQRnban+ChPztF3om5ffcm8yp3GmLCZcwAXl2I2jEji9+GZxknjC/CJbXxkd4ajsE8pnOHF4VSnuR+0X2tDQs63fHFTTaHaZs9RbS3vQ5uxNrQzoYDtkfas2oaF8Mx8lOcw+D+ThErAt03kJQa1znypMpoAKsR9guqA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0701MB1715; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1715; 20:xLQ/v1TO62/cjfkEwxyxpM4onftQohs1TND2kxIoxurEThAxtl/DTemvrHZvJzQo20qYU4jIDDYcgSJ3eOF3YU74WfGq8cfXewIgH/0zfjR3ntPem6wVt1VpIU47/BiWhj01taXEvIigtXO2kOZ1RnD0LMZA6pzDKHvBMmMo3ZaLzE2xg4dyjMmG3UDM15BJJABRKa2UqNIi+PjAMXTQBGVi91mc9cC+wzRMRV/kzAIBh6qZRplE1tRbNfY/+5XIWVNXMpJfA47bZaZZJVmsaXxY4sYInC1gvlWptOOKCyB92mG2ieaU8swzdLp9FkYoEVbEMCsgDrv9D+ccD5eHqvDmAwXYZS/bru5xUMShtL15i0D7jfpKrVPVXmq3O6s57ZoMQqrdSQuB/J1kJnr6etQzr+yGjpt4Z8EXHez8I77zmQFVloy8j9kHWN/bYGzOqHx+lTfd4bpEWnPgpdGjIAE6sL4YuxTbfqXDymKRA4oudm5wKM37faPR2ExcKlytEpL0CdRU3X8IsVQ769e0rp2DgD0ipv2Dg3Kqk3MkCE1iDXBkgZXZgXNAEd0sXrgq24Lf8g9L393wPbKsIAT2MwWNGT/ICrSFTCKCLy2DjWY= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(236414709691187); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR0701MB1715; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0701MB1715; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1715; 4:19tLHhExUEwp9MrImdVvA5EkBaUQEwZsSeOgjHSq2b3EGFVE0PP3rVSbbqwmwzwnJs7yFgQorOv71kv3uh5NUHKSiU6o7EIqj9bx/Z0ezIJWeXfkPfD/jLLTGu5JmbRnItZIkGyumS9KjpWt5aL1QVSmzITrRPG5nphnwDxoqOt7BRCtT+tzVbxoH7A9Imw+BvEZCq4jLflJY75/JsTcji525ih0v0kb22/W+TrLNmHVCJDmbwO0oP4WxgUr+MPLLhS2UG9v3UG/QdIYc602zOdQL+nU7A8Ztz4LfZuJgkS7ecAWq4aTtK/KibEXYxYJ+ALPmLy8NYoElXMKnT9FADj/Lzb0PpqTcQQlWbFMnsSoreS2JUFS2iHx9/mWVQq7rhgwUi5VHdHDZZgxV/RejDsE/ENzdNA/oBJt7JvZaJJL7LrzFjmf8vIj/Z17T2zu X-Forefront-PRVS: 077884B8B5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6069001)(6009001)(199003)(24454002)(189002)(66066001)(77096005)(92566002)(4001350100001)(33656002)(81156007)(86362001)(2950100001)(83506001)(87976001)(5004730100002)(110136002)(93886004)(586003)(54356999)(97736004)(50466002)(47776003)(19580395003)(76176999)(101416001)(5008740100001)(1076002)(1096002)(5001960100002)(3846002)(23726003)(106356001)(122386002)(40100003)(6116002)(97756001)(105586002)(42186005)(50986999)(189998001)(46406003)(61506002)(19580405001)(7099028)(357404004); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0701MB1715; H:localhost.localdomain; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: caviumnetworks.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0701MB1715; 23:AcOU0ySr5AaUDpmujEe6HHEXqT3g4jbalRR0pod?= =?us-ascii?Q?Dnw8vJENRjYTCLYbbvHV+CVdAWHV3XO3GHIYrfJAqieoAngLkiLhcznl/tG5?= =?us-ascii?Q?/10nXml5xjfzCMuqEI6nU9uy8ZnyBlny64oe5x+MBC+rMtQuyMzw90n3D2si?= =?us-ascii?Q?1ODaY9jZh3kZxu99dSudx7G5XDm6jZJtzd3aL7WXOUf+OY6qmnYgUo7zhxqs?= =?us-ascii?Q?JAGmT9Z7rncBhd/SVzgxa0XDJ79ZlFy4edOOP0WhZ0MlAlGCGwk/gCejaylP?= =?us-ascii?Q?bCu5He6I/0LCb5wilT+KjFlNnoCENZjE1g0IjfTUScADxZAuNlE5g8o/WCWL?= =?us-ascii?Q?mGYTIid0uBh4iwGX9N60DVtMjKLNs9dzVgCPQGlcR+eb8HTuO/7YEJoIWNPy?= =?us-ascii?Q?APYBnVY922zdfOBt9kqJgaln9UMeD9RF0Lo9RHTQ6MAgUC/kgE2tmvvWCXMV?= =?us-ascii?Q?KT6u3R1xGKjKMRdVCoiswHyfqN5svn0c9h0VjWzE+6ZD0/9uZsNE7crH0pG8?= =?us-ascii?Q?nxuExBBS7XDpNNf2hEXV5IDFrfD/KVHLC3rIN6yaKh95R6pYZKevf4J4TKPa?= =?us-ascii?Q?2sLSpZjBBuX5kieT5FFS5vY97zsDG1ESD3rylCiYZgxvXNsJwIqhxb0ly7Vs?= =?us-ascii?Q?86oo6e4pcnFpqvpsZ34X34/PYdXIb2BxvjndrpM97Qzplm7vOn2/kv89wbYi?= =?us-ascii?Q?NW4Ud4ritO9WQtevrBK3M6AqZLG9mWceKHjlTjbJVJwRz649HSjnGhgYufSv?= =?us-ascii?Q?aoh9wTGZffKZbHReUTUHqjQvFjjsBAjMRjukeDf2nbP1tmEGqxwwVxJDcyjm?= =?us-ascii?Q?FWIqvY3EctfFhjEUhXVj3I06t12kshiAzfOYtM6+LMHyQzb5TgokkKRh0EG9?= =?us-ascii?Q?bRpSL0EA6lqznv+EhNRgEMusIqySbu+2dV3VNMX8uHm0Z7obAkmQ3+scQtFB?= =?us-ascii?Q?VUFaYcTjesu6Ux5c0KxW+LW/5mVGB/XBTYzqEkuTY/iqfJJ2gfdr6ZcOS4JW?= =?us-ascii?Q?fWCe4uM8xxjun9ST85vBrIzYSwIGuRov+86Nv6CrZ9avC1H6f1HnqV0Y6MOQ?= =?us-ascii?Q?OAg41J6zUi9Z1HwJ6uoKwswur80JU9zk967E2Nxs8ecNqSCh1x80faF7kd4h?= =?us-ascii?Q?ek1rgukbloNJ+viw75hdVbVzMoe0JVwS/R+I8uYdkVOG5DuxKUnzxxdEjR8w?= =?us-ascii?Q?EHXAYuG+V4O5CUcg=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1715; 5:YWUnGVM6RDDyW+f0OrENtxYJQr3bdR1sGbGi5No97b5FbBE4l+X+n2WcVljCVnIZkfu+KVFk976Jg4so0ro3+F13lP3IEd8Des7QgHFZm8a1mk/E3EdRmrESehBJIohcq77Qq/gOuskXWrNlUkRqJA==; 24:JwLaRmR7/NaREWldmqnG/DP/w+Kk+s58JKcDbdMyT0Mg63xmTxPGkY35zPPF98/IgOOSeF4Lo/aZPqOeZ6X/UgxTSxrxBI01lcIJN2UJgVY= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Dec 2015 08:03:25.8065 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0701MB1715 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 08:03:31 -0000 On Wed, Dec 02, 2015 at 02:54:52PM +0800, Jianbo Liu wrote: > On 2 December 2015 at 00:41, Jerin Jacob wrote: > > On Tue, Dec 01, 2015 at 01:41:15PM -0500, Jianbo Liu wrote: > >> Adds ARM NEON support for lpm. > >> And enables table/pipeline libraries which depend on lpm. > > > > I already sent the patch on the same yesterday. > > We can converge the patches after the discussion. > > Please check "[dpdk-dev] [PATCH 0/3] add lpm support for NEON" on ml > > > Yes, I have read your patch. But there are many differences, so I sent > mine for your reviewing :) > > > > >> > >> Signed-off-by: Jianbo Liu > >> --- > >> config/defconfig_arm-armv7a-linuxapp-gcc | 3 - > >> config/defconfig_arm64-armv8a-linuxapp-gcc | 3 - > >> lib/librte_eal/common/include/arch/arm/rte_vect.h | 28 ++++++++++ > >> lib/librte_lpm/rte_lpm.h | 68 ++++++++++++++++------- > >> 4 files changed, 77 insertions(+), 25 deletions(-) > >> > >> diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc > >> index cbebd64..efffa1f 100644 > >> --- a/config/defconfig_arm-armv7a-linuxapp-gcc > >> +++ b/config/defconfig_arm-armv7a-linuxapp-gcc > >> @@ -53,9 +53,6 @@ CONFIG_RTE_LIBRTE_KNI=n > >> CONFIG_RTE_EAL_IGB_UIO=n > >> > >> # fails to compile on ARM > >> -CONFIG_RTE_LIBRTE_LPM=n > >> -CONFIG_RTE_LIBRTE_TABLE=n > >> -CONFIG_RTE_LIBRTE_PIPELINE=n > >> CONFIG_RTE_SCHED_VECTOR=n > >> > >> # cannot use those on ARM > >> diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc > >> index 504f3ed..57f7941 100644 > >> --- a/config/defconfig_arm64-armv8a-linuxapp-gcc > >> +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc > >> @@ -51,7 +51,4 @@ CONFIG_RTE_LIBRTE_IVSHMEM=n > >> CONFIG_RTE_LIBRTE_FM10K_PMD=n > >> CONFIG_RTE_LIBRTE_I40E_PMD=n > >> > >> -CONFIG_RTE_LIBRTE_LPM=n > >> -CONFIG_RTE_LIBRTE_TABLE=n > >> -CONFIG_RTE_LIBRTE_PIPELINE=n > >> CONFIG_RTE_SCHED_VECTOR=n > >> diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h b/lib/librte_eal/common/include/arch/arm/rte_vect.h > >> index a33c054..7437711 100644 > >> --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h > >> +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h > >> @@ -41,6 +41,8 @@ extern "C" { > >> > >> typedef int32x4_t xmm_t; > >> > >> +typedef int32x4_t __m128i; > >> + > >> #define XMM_SIZE (sizeof(xmm_t)) > >> #define XMM_MASK (XMM_SIZE - 1) > >> > >> @@ -53,6 +55,32 @@ typedef union rte_xmm { > >> double pd[XMM_SIZE / sizeof(double)]; > >> } __attribute__((aligned(16))) rte_xmm_t; > >> > >> +static __inline __m128i > >> +_mm_set_epi32(int i3, int i2, int i1, int i0) > >> +{ > >> + int32_t r[4] = {i0, i1, i2, i3}; > >> + > >> + return vld1q_s32(r); > >> +} > >> + > >> +static __inline __m128i > >> +_mm_loadu_si128(__m128i *p) > >> +{ > >> + return vld1q_s32((int32_t *)p); > >> +} > >> + > >> +static __inline __m128i > >> +_mm_set1_epi32(int i) > >> +{ > >> + return vdupq_n_s32(i); > >> +} > >> + > >> +static __inline __m128i > >> +_mm_and_si128(__m128i a, __m128i b) > >> +{ > >> + return vandq_s32(a, b); > >> +} > >> + IMO, it's not always good to emulate GCC defined intrinsics of other architecture. What if a legacy DPDK application has such mappings then BOOM, multiple definition, which one is correct? which one to comment it out? Integration pain starts for DPDK library consumer:-( > > > > IMO, it makes sense to not emulate the SSE intrinsics with NEON > > Let's create the rte_vect_* as required. look at the existing patch. > > > I thought of creating a layer of SIMD over all the platforms before. > But can't you see it make things complicated, considering there are > only few simple intrinsic to implement? Not true, There were, a lot of SSE intrinsics needs be to emulated for ACL NEON implementation if I were to take this approach and emulation comes with the cost. So my take is, lets the each architecture implementation for specific SIMD version of DPDK API in the library should have the freedom to implement the API in NATIVE. And let's create only rte_vect_* abstraction only for using that API/library. Which boils down to have very minimal rte_vect_* abstraction to load, store, set not beyond that. This makes clear "contract" between DPDK library and the applications. and make easy for remaning new architecture porting effort in DPDK. Imagine how your proposed function will look like if new architecture wants to implement "optimized" version of rte_lpm_lookupx4 > If do so, we also need to explain to others how to use these interfaces. > Besides, this patch did the smallest changes to the original code, and > more likely to be accepted by others. other patch makes no changes to IA version of rte_lpm_lookupx4.I thought that make reviewer easy to review the changes in architecture perspective. > > > > >> #ifdef RTE_ARCH_ARM > >> /* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */ > >> static __inline uint8x16_t > >> diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h > >> index c299ce2..c76c07d 100644 > >> --- a/lib/librte_lpm/rte_lpm.h > >> +++ b/lib/librte_lpm/rte_lpm.h > >> @@ -361,6 +361,47 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t * ips, > >> /* Mask four results. */ > >> #define RTE_LPM_MASKX4_RES UINT64_C(0x00ff00ff00ff00ff) > >> > >> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64) > > > > Separate out arm implementation to the different header file. > > Too many ifdef looks odd in the header file and difficult to manage. > > > But there are many ifdefs already. > And It seems unreasonable to add a new file only for one small function. > small or big, its matter of each architecture to have the freedom for the optimized version for the implementation. What if other architecture demands to write this function in assembly or restructure it for performance improvement? > > > >> +static inline void > >> +rte_lpm_tbl24_val4(const struct rte_lpm *lpm, int32x4_t ip, uint16_t tbl[4]) > >> +{ > >> + uint32x4_t i24; > >> + uint32_t idx[4]; > >> + > >> + /* get 4 indexes for tbl24[]. */ > >> + i24 = vshrq_n_u32(vreinterpretq_u32_s32(ip), CHAR_BIT); > >> + vst1q_u32(idx, i24); > >> + > >> + /* extract values from tbl24[] */ > >> + tbl[0] = *(const uint16_t *)&lpm->tbl24[idx[0]]; > >> + tbl[1] = *(const uint16_t *)&lpm->tbl24[idx[1]]; > >> + tbl[2] = *(const uint16_t *)&lpm->tbl24[idx[2]]; > >> + tbl[3] = *(const uint16_t *)&lpm->tbl24[idx[3]]; > >> +} > > > > Nice. There is an improvement in this portion code wrt my patch. This is > > a candidate for convergence. > > > > > >> +#else > >> +static inline void > >> +rte_lpm_tbl24_val4(const struct rte_lpm *lpm, __m128i ip, uint16_t tbl[4]) > >> +{ > >> + __m128i i24; > >> + uint64_t idx; > >> + > >> + /* get 4 indexes for tbl24[]. */ > >> + i24 = _mm_srli_epi32(ip, CHAR_BIT); > >> + > >> + /* extract values from tbl24[] */ > >> + idx = _mm_cvtsi128_si64(i24); > >> + i24 = _mm_srli_si128(i24, sizeof(uint64_t)); > >> + > >> + tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx]; > >> + tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32]; > >> + > >> + idx = _mm_cvtsi128_si64(i24); > >> + > >> + tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx]; > >> + tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32]; > >> +} > >> +#endif > >> + > >> /** > >> * Lookup four IP addresses in an LPM table. > >> * > >> @@ -381,17 +422,19 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const uint32_t * ips, > >> * if lookup would fail. > >> */ > >> static inline void > >> +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64) > >> +rte_lpm_lookupx4(const struct rte_lpm *lpm, int32x4_t ip, uint16_t hop[4], > >> + uint16_t defv) > > > > This would call for change in the change the ABI, > > IMO, __m128i can be used to represent 128bit vector to avoid ABI chang > > > This redefine rte_lpm_lookupx4 is unncessary, I will remove it, so no > ABI change. > And there only one ifdef for ARM platforms left. > > > > >> +#else > > separate out arm implementation to the different header file. Too many > > ifdef looks odd in the header file. > > > > Could you rebase your patch based on existing patch and send the > > improvement portion as separate patch or I can send update patch with > > your improvements and with your signoff. > > > > > >> rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4], > >> uint16_t defv) > >> +#endif > >> { > >> - __m128i i24; > >> rte_xmm_t i8; > >> uint16_t tbl[4]; > >> - uint64_t idx, pt; > >> - > >> - const __m128i mask8 = > >> - _mm_set_epi32(UINT8_MAX, UINT8_MAX, UINT8_MAX, UINT8_MAX); > >> + uint64_t pt; > >> > >> + const __m128i mask8 = _mm_set1_epi32(UINT8_MAX); > >> /* > >> * RTE_LPM_VALID_EXT_ENTRY_BITMASK for 4 LPM entries > >> * as one 64-bit value (0x0300030003000300). > >> @@ -412,20 +455,7 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4], > >> (uint64_t)RTE_LPM_LOOKUP_SUCCESS << 32 | > >> (uint64_t)RTE_LPM_LOOKUP_SUCCESS << 48); > >> > >> - /* get 4 indexes for tbl24[]. */ > >> - i24 = _mm_srli_epi32(ip, CHAR_BIT); > >> - > >> - /* extract values from tbl24[] */ > >> - idx = _mm_cvtsi128_si64(i24); > >> - i24 = _mm_srli_si128(i24, sizeof(uint64_t)); > >> - > >> - tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx]; > >> - tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32]; > >> - > >> - idx = _mm_cvtsi128_si64(i24); > >> - > >> - tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx]; > >> - tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32]; > >> + rte_lpm_tbl24_val4(lpm, ip, tbl); > >> > >> /* get 4 indexes for tbl8[]. */ > >> i8.x = _mm_and_si128(ip, mask8); > >> -- > >> 1.8.3.1 > >>