From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0065.outbound.protection.outlook.com [207.46.100.65]) by dpdk.org (Postfix) with ESMTP id C24FC5913 for ; Wed, 2 Dec 2015 15:52:05 +0100 (CET) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@caviumnetworks.com; Received: from localhost.localdomain (122.167.201.210) by BY1PR0701MB1722.namprd07.prod.outlook.com (10.162.111.141) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 2 Dec 2015 14:52:02 +0000 Date: Wed, 2 Dec 2015 20:21:45 +0530 From: Jerin Jacob To: Jan Viktorin Message-ID: <20151202145144.GB12316@localhost.localdomain> References: <1448904253-12929-1-git-send-email-jerin.jacob@caviumnetworks.com> <1448904253-12929-2-git-send-email-jerin.jacob@caviumnetworks.com> <20151202144334.1a66676d@pcviktorin.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20151202144334.1a66676d@pcviktorin.fit.vutbr.cz> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [122.167.201.210] X-ClientProxiedBy: MA1PR01CA0017.INDPRD01.PROD.OUTLOOK.COM (25.164.117.24) To BY1PR0701MB1722.namprd07.prod.outlook.com (25.162.111.141) X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1722; 2:XmoNBMb5X2L31uNTAnntfHdP8AnSPhVrkqVVkIp2gSTDxNaX2PW0nagKR7eqz++YIFsIdY5j2IMD94jMKLZ2nOeFabdHwLuzzyGNQRL/2QEopdZqoDi9BMafEHtCewx8GOz+kU9Sxw692ungj6dElg==; 3:bl4YlQqKJ4G63iX6QBD2H2C+sGvm1E406GUuoU9IiJZoFZO59VRFPBq9G3B3yRq3ygwj8VK7D2TY1ktGvBKDzOj2wDDZrTu5AkK22MdJqJ6DOl9zg8KuNa7RiXa0mcTY; 25:3HztRgPSXz1r+OlKAEU+tMTF0i5XVqUgKdcCaaX4vLM4dx8qPpVdP4vOMBM2JU4ILhObxrc6D19sW67I2bcytzHq6TkZHBKmfn2nrbGWnMhynFicQXpWn96u0aaxQlVNdJMbWJCw7sKo9/7ZNh8UBvbTlG0BqpJ8ZBrwGb8Wpe5j7Cpj9jMcbtxxfwVqb5bzZMqLxHD+yNubqEEnwmYz36ZkRoiJ90iwxyYkNRFLz5xyMOlJuDmR2j0anJya04l+ZdKOeETTiAumoMibOoe4eg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0701MB1722; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1722; 20:5vIAjXnJSCPmC+TPcEyqQBJTWod3OjOkSQ2yeUWT9+jNAB9VRM1zC6dxOE0cuwUgZ+Q0OECi6b4LWtPvNadhBQqU067QDhKy2+/LjNGmt/XLWqJNxsKkgIc4GoQI8r7MK0i/trqAAHoO/P9a5kbdmq4VJ9WMeC1a18hhYrtXaJ62J+Q4jxt5fbPQr8NKkTIcfX6GIzS/kWnhpTApQ0hI0geo0e2doHKvj4DbqQ2PKVAP7OErKRUzTceip5adB2TcBNasGjNKLngIaR13OJ9Ij1m0F4UeFdpDGsebTvkap2c33iBMZJ9bF8w6ddB7wv9LHQ6+Yk2XIhvOwI3HHP6c3COem7lSwdvfUx3OCJ7WZWEFVZVqfFYxuWHAs7kr44SwEjZ2K74x2txTar8105b7MDYVYVlfVQNsHq7y0Mxr/HWY5ShKApv2LhAE393PS9+k4G6Cp1K0rT6TKji+xS8WdxO5Y4WMlA/AaqS5PFmbkla9CCLRHtyshFd/rzb1zwZfetYYOslzYChZxl9b15x+k2ImU3hKfjSw/1wpUfaRdTywM5EPkvb0Z6tzeqn1xfu3FkKxU3gtJp/zzRsxXpXFApMhH7wvv38KfTwSSE9W/VA= 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)(8121501046)(5005006)(10201501046)(3002001); SRVR:BY1PR0701MB1722; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0701MB1722; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1722; 4:RPaqEE76ino8ZmZDqbovMMQ0nbjNG0yorjnbqc6423y35v9tGgoYixQ7Y6GiC+0TgH8RDejxhPDjl5QcxrgKpFwowQM+vbnQnoAC8VOmK4a4EHLYjD6qSvbqyq4zs/H081QXMmtAB17gRpdX/dZ+j7SHP6s5eeJooAwfVhSUXh6TzoX+OIVx7UI9FR4BXEs/X8S/KGjvS6Fwth4WvCevNqnYRY/DId90T/x8R2lGHxPRqAojH/A91UKuXNH03DgfftCqs8tZL/0vNA3mw2jb2qs2AcOdF+H4z9hX56Nt+w/rxeAkFmFmWJnw5TO1OndFlrnJG43Mryjf5EUAaHGAI3TAtHF2XHTjFd3Y6W6HQe7AjEOEtv2r4Zxs4LfmyM0KFhulpusS5FDDHI6oPwycvPNQCxg74oMS41O2lCuvqYG0FX+jVVknLgTlwz7WHkp1 X-Forefront-PRVS: 077884B8B5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(6069001)(252514010)(199003)(189002)(24454002)(77096005)(50986999)(101416001)(110136002)(97756001)(19580405001)(87976001)(15974865002)(33656002)(5004730100002)(50466002)(2950100001)(5008740100001)(5001960100002)(6116002)(19580395003)(1076002)(42186005)(92566002)(3846002)(81156007)(23726003)(1096002)(586003)(105586002)(40100003)(61506002)(4001350100001)(189998001)(46406003)(76176999)(66066001)(97736004)(54356999)(106356001)(86362001)(83506001)(47776003)(122386002)(7099028); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0701MB1722; 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; BY1PR0701MB1722; 23:jbEP3bbZbnj7oUZmgkVkpnlOEZrO84b7X7BBoNW?= =?us-ascii?Q?O3udcM13pdnIupWjCZVjCN3TuEhXCT9JBlskf1z1odD+uIx1wuY1yDmrd5Eg?= =?us-ascii?Q?sWEhg2xcR3DC+gdzkFU+FBnzG2DTiBYTvr7FfMv7hQ4+ID7QUbME0f6d6iFc?= =?us-ascii?Q?0riUAonykwBMg6bRtR3Z9gvuNIGiLAEMMh8BZTXyo3NVHwbrsqYIH+ZUsq7+?= =?us-ascii?Q?/B5rfipxSlGFWKiv19SjjsT3PEabf2Nf07IgDGzSY7dpHmh1LoJUL07Ob2gZ?= =?us-ascii?Q?t4dPWUvXhKY2XfraQhDPPhYBgVOd8O2CDweEaRW7rQkKD2hrD6M9uDthj4Yg?= =?us-ascii?Q?g3OlezK4eI79o1hbZrnXMV/Y0pDjB+g9cLYKGjLjEHBNPrjdcYcrKFzym5rN?= =?us-ascii?Q?z8NE5LxH9u/UfcO2SUEttykzIrGCwcxyK4QbZPV0H5AoVBbybgSPOTehZ4DU?= =?us-ascii?Q?t3ArWyz5pzyJneqggiNnocCQUHYT5oZPkk3Pkk4ePFp9LNDCA3CQGodtpcuM?= =?us-ascii?Q?HqS9Wortwm9SQJabTq6TDEw+V5mJle6Yl8EPl+DTUos1nnfeSqcUaisW7wYd?= =?us-ascii?Q?/aFzvA5ofzqOUFBnhJWscJGDHzrXYo0eGZ09zEmIzCvNm3xbRfhFxjr8VkRW?= =?us-ascii?Q?GH6MKX8nUtWLNJJ8HPB8ecsi4NHKcH3Zbt8pHHCCWaah90sIu0NvTRWgcR9d?= =?us-ascii?Q?DzpHDxMT1FGTIXlh/6I/ggfenoPIFSUUFPnDeSJJPBQYQ+ozagjRgkTxkOon?= =?us-ascii?Q?3LL7cuYt8fltBaK8dW2oRXeXXTZA1fMXmRSD9M2XjcuZu6Zg9EvBtflAd7Zy?= =?us-ascii?Q?g/9pja7Jwv8rs9/6jhVBc0UHUEL+QFLuNivUZGuaLDwLHqDUijg7XNHzt/7v?= =?us-ascii?Q?ZR2XZD/UGsyX6Q0A4RT6OSX/mceIUPe0ua2dOwoJApIy0odPgWgoTfyI1VIl?= =?us-ascii?Q?epOH2Edn8J9CdW5v5Z/f4LMQv0xhaT29YtWjfJEur6VtG9m9I0RX5nLdYuoE?= =?us-ascii?Q?m4RpdXXjZovMufiaVQnmt7HKh3jRT/Xd7DX+Uoi7QLHRxOheHERkQiLK14uR?= =?us-ascii?Q?Cf/nnodTUZPw9tE8vPYSh3ujuCMXvZjgJ0MCZaD/PyrzsO9HTvz4LDc3NQ+W?= =?us-ascii?Q?pw/I+OKwD0vPTU54rH82aaw8ajytV+hSZ2OIroebIGFxWdobgRy8F54HtzYH?= =?us-ascii?Q?NyA9PrjtyUcb4Vpk=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1722; 5:PxkG4q5g+0EH/c2KQLGJcH26ShM4UbchN+sER3GsquiBSf8BEU0XguRZj6tweFE9gKPLuCgIYP8UyUG6rlk6b9yqv1UzAOInknYuq1wcYH+iZN8nfezQgtFl5mdairBUJds9oSoNNMz1Np9MukCr6w==; 24:+ivtGvLOzAydBYgTSdSCByBuVHHQ+V45rHOikGcD+ZRw+OCWmeJZ8r1ALHr9DG6I96M0ax4HYtaxQrjyThDcMtAY1WvYSBodf6TMU6+ZfIg= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Dec 2015 14:52:02.5002 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0701MB1722 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 1/3] eal: introduce rte_vect_* abstractions 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 14:52:06 -0000 On Wed, Dec 02, 2015 at 02:43:34PM +0100, Jan Viktorin wrote: > On Mon, 30 Nov 2015 22:54:11 +0530 > Jerin Jacob wrote: > > > introduce rte_vect_* abstractions to remove SSE/AVX specific > > code in the common code(i.e the test applications) > > > > The patch does not provide any functional change for IA, the goal is to > > Does IA mean Intel Architecture? Yes. > > > have infrastructure to reuse the common vector-based test code across > > all the architectures. > > > > Signed-off-by: Jerin Jacob > > --- > > lib/librte_eal/common/include/arch/arm/rte_vect.h | 17 ++++++++++++++++- > > lib/librte_eal/common/include/arch/x86/rte_vect.h | 8 ++++++++ > > 2 files changed, 24 insertions(+), 1 deletion(-) > > > > 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 21cdb4d..d300951 100644 > > --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h > > +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h > > @@ -33,13 +33,14 @@ > > #ifndef _RTE_VECT_ARM_H_ > > #define _RTE_VECT_ARM_H_ > > > > -#include "arm_neon.h" > > +#include > > > > #ifdef __cplusplus > > extern "C" { > > #endif > > > > typedef int32x4_t xmm_t; > > +typedef int32x4_t __m128i; > > As Jianbo pointed out recently, the __m128i type should be refactored in > a general rte_vect API too. If we do something like > > #if SSE > typedef __m128i rte_128i; > #elif NEON > typedef int32x4_y rte_128i; > #endif > > does it make somebody angry? I am afraid that it will influence a lot of > code. However, from the ABI point of view, it is OK, isn't it? > > > > > #define XMM_SIZE (sizeof(xmm_t)) > > #define XMM_MASK (XMM_SIZE - 1) > > @@ -53,6 +54,20 @@ typedef union rte_xmm { > > double pd[XMM_SIZE / sizeof(double)]; > > } __attribute__((aligned(16))) rte_xmm_t; > > > > +/* rte_vect_* abstraction implementation using NEON */ > > + > > +/* loads the __m128i value from address p(does not need to be 16-byte aligned)*/ > > +#define rte_vect_loadu_sil128(p) vld1q_s32((const int32_t *)p) > > + > > +/* sets the 4 signed 32-bit integer values and returns the __m128i variable */ > > +static inline __m128i __attribute__((always_inline)) > > +rte_vect_set_epi32(int i3, int i2, int i1, int i0) > > +{ > > + int32_t data[4] = {i0, i1, i2, i3}; > > + > > + return vld1q_s32(data); > > +} > > + > > #ifdef __cplusplus > > } > > #endif > > diff --git a/lib/librte_eal/common/include/arch/x86/rte_vect.h b/lib/librte_eal/common/include/arch/x86/rte_vect.h > > index b698797..91c6523 100644 > > --- a/lib/librte_eal/common/include/arch/x86/rte_vect.h > > +++ b/lib/librte_eal/common/include/arch/x86/rte_vect.h > > @@ -125,6 +125,14 @@ typedef union rte_ymm { > > }) > > #endif /* (defined(__ICC) && __ICC < 1210) */ > > > > +/* rte_vect_* abstraction implementation using SSE */ > > + > > +/* loads the __m128i value from address p(does not need to be 16-byte aligned)*/ > > +#define rte_vect_loadu_sil128(p) _mm_loadu_si128(p) > > + > > +/* sets the 4 signed 32-bit integer values and returns the __m128i variable */ > > +#define rte_vect_set_epi32(i3, i2, i1, i0) _mm_set_epi32(i3, i2, i1, i0) > > + > > #ifdef __cplusplus > > } > > #endif > > I like this approach. It is a question whether to inherit names from > SSE. However, why to reinvent the wheel... > > We probably need other people to give their ideas about such > generalization of the API. Yes, I would like get the feedback from other people. ret_vect_* abstraction only for the common code (i.e test code) which typically used to call the SIMD DPDK API's across the architecture. > > I think, there should be an autotest of the rte_vect API. Is it > possible to create one? Yes > > Regards > Jan > > -- > Jan Viktorin E-mail: Viktorin@RehiveTech.com > System Architect Web: www.RehiveTech.com > RehiveTech > Brno, Czech Republic