From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0063.outbound.protection.outlook.com [157.56.110.63]) by dpdk.org (Postfix) with ESMTP id ACC644AC7 for ; Tue, 15 Mar 2016 20:43:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-caviumnetworks-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8RqmUDJj0OACXNThdqJmDyBNv/TKfydGWyXnm1muA60=; b=sy0EWAs/oI5MEyiP8xIl/DKVBDgcKD7NxHFFR+rydJS5wNQ4C7ZiZJKpP+rHtcoEw2M1WjtcqfKltFZAFsdw2BfsHi7c3ehw4qIgljmMcx8cZXaiwz7j1YAwG7zA+QRih1dOVS35QxonZbj3/2EGVDcibXqoKpSwX2v42aMubf8= Received: from CO2PR0701MB1032.namprd07.prod.outlook.com (10.160.10.20) by CO2PR0701MB1029.namprd07.prod.outlook.com (10.160.10.17) with Microsoft SMTP Server (TLS) id 15.1.434.16; Tue, 15 Mar 2016 19:42:57 +0000 Received: from CO2PR0701MB1032.namprd07.prod.outlook.com ([10.160.10.20]) by CO2PR0701MB1032.namprd07.prod.outlook.com ([10.160.10.20]) with mapi id 15.01.0434.016; Tue, 15 Mar 2016 19:42:57 +0000 From: "Czekaj, Maciej" To: "Kulasek, TomaszX" , "thomas.monjalon@6wind.com" CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v3] examples/l3fwd: em path performance fix Thread-Index: AQHRe48XWYQEdOcjuke3uJ9kWBKJ1J9UbXuAgAAX5ACABhJXAIAABPIAgAAVkgCAADAFvA== Date: Tue, 15 Mar 2016 19:42:57 +0000 Message-ID: References: <1457441937-2176-1-git-send-email-tomaszx.kulasek@intel.com> <3042915272161B4EB253DA4D77EB373A14E6B4B1@IRSMSX102.ger.corp.intel.com> <3042915272161B4EB253DA4D77EB373A14E6BDDA@IRSMSX102.ger.corp.intel.com> <4500844.l7uGIisiEg@xps13>, <3042915272161B4EB253DA4D77EB373A14E6BE0E@IRSMSX102.ger.corp.intel.com> In-Reply-To: <3042915272161B4EB253DA4D77EB373A14E6BE0E@IRSMSX102.ger.corp.intel.com> Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dpdk.org; dkim=none (message not signed) header.d=none;dpdk.org; dmarc=none action=none header.from=caviumnetworks.com; x-originating-ip: [80.82.22.190] x-ms-office365-filtering-correlation-id: 4f64a397-c337-4c21-bc06-08d34d0a027f x-microsoft-exchange-diagnostics: 1; CO2PR0701MB1029; 5:KrWwm68PXHr2cNInE3Un2j9SLbhsWYV6pskNOZUbH7FW3xhasd8/RmpZKNB9dDFLdUEhpcj1Wa1oHlErEuogreVVRcGAkA1D3v3TyEROjni2PgbrZKof+TOOTqssWRq0VPMuUiGroJCI7/5zAWOCmw==; 24:xCp+Fy5b0upTdDJ6WlzwBpi1UpWB7YV+kCK5R2xfurecISwkflQOmC6kvB1YP1giNZLmvlD41k4DCOcQhfrO8GkcSIstjnjx3RN8MGuVPAI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR0701MB1029; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:CO2PR0701MB1029; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0701MB1029; x-forefront-prvs: 08828D20BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377424004)(13464003)(102836003)(1096002)(1220700001)(5003600100002)(3846002)(2501003)(586003)(3280700002)(92566002)(2906002)(3660700001)(6116002)(11100500001)(5002640100001)(54356999)(4326007)(76176999)(50986999)(81166005)(86362001)(19580405001)(19580395003)(33656002)(77096005)(5008740100001)(229853001)(106116001)(99286002)(122556002)(66066001)(76576001)(5004730100002)(74316001)(93886004)(189998001)(5001770100001)(2900100001)(10400500002)(2950100001)(87936001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR0701MB1029; H:CO2PR0701MB1032.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2016 19:42:57.0215 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0701MB1029 Subject: [dpdk-dev] Odp.: [PATCH v3] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 19:43:01 -0000 ________________________________________ Od: Kulasek, TomaszX Wys=B3ane: 15 marca 2016 17:06 Do: Thomas Monjalon; Czekaj, Maciej DW: dev@dpdk.org Temat: RE: [dpdk-dev] [PATCH v3] examples/l3fwd: em path performance fix > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Tuesday, March 15, 2016 15:50 > To: Kulasek, TomaszX ; Maciej Czekaj > > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3] examples/l3fwd: em path performance fi= x > > 2016-03-15 14:31, Kulasek, TomaszX: > > From: Kulasek, TomaszX > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > > There is an error: > > > > examples/l3fwd/l3fwd_em_hlm_sse.h:72:38: error: > > > > incompatible type for argument 2 of =91_mm_and_si128=92 > > > > > > It's caused by > > > > > > commit 64d3955de1de4d7879a0930a6d2f501369d3445a > > > Author: Maciej Czekaj > > > Date: Thu Mar 10 17:06:22 2016 +0100 > > > > > > examples/l3fwd: fix ARM build > > > > > > Enable NEON support in exact match mode. > > > l3fwd example did not compile on ARM due to SSE2 instrincics used > > > in generic part. > > > Some instrinsins were used to initialize data structures and > > > those were > > > replaced by ordinary structure initalization. > > > All SSE2 intrinsics used in forwarding, i.e. masking the IP/TCP > header > > > are moved to single inline function and made arch-specific. > > > > > > Signed-off-by: Maciej Czekaj > > > > > > Which doesn't include rework of l3fwd_em_hlm_sse.h file. > > > > > > When you compile it now with global "#define HASH_MULTI_LOOKUP 1" > > > and alternative classification is used, and compilation will also fai= l > now. > > > > > > I need a little bit more time to investigate it, because I'm not an > > > expert in ARM. It will be nice if Maciej will help me in that. > > > > > > Tomasz > > > > Will be that ok for you to disable this path for arm? > > Please, what do you mean? > Maciej, have you looked at this issue? This fix uses platform specific part of code which wasn't reworked in previ= ous patch for ARM. It causes compilation error. What I mean, is to leave current classification path for ARM and turn on al= ternative only for Intel platform. Like that: 60 +#if defined(NO_HASH_MULTI_LOOKUP) || defined(__ARM_NEON) 61 #include "l3fwd_em_sse.h" 62 #else 63 #include "l3fwd_em_hlm_sse.h" Thanks guys for pointing this out. The issue is that after my patch mask0, = mask1 and mask2 are now defined as: static rte_xmm_t mask0; static rte_xmm_t mask1; static rte_xmm_t mask2; rte_xmm_t is a union with xmm_t field inside. Apparently, I overlooked the HASH_MULTI_LOOKUP define I can provide a quick fix for that, I need to rename all maskN references t= o maskN.x, to point out to xmm_t variable. E.g. the following diff is fixin= g the compilation. diff --git a/examples/l3fwd/l3fwd_em_hlm_sse.h b/examples/l3fwd/l3fwd_em_hl= m_sse.h index d3388da..eb23163 100644 --- a/examples/l3fwd/l3fwd_em_hlm_sse.h +++ b/examples/l3fwd/l3fwd_em_hlm_sse.h @@ -77,14 +77,14 @@ em_get_dst_port_ipv4x8(struct lcore_conf *qconf, struct= rte_mbuf *m[8], sizeof(struct ether_hdr) + offsetof(struct ipv4_hdr, time_to_live))); =20 - key[0].xmm =3D _mm_and_si128(data[0], mask0); - key[1].xmm =3D _mm_and_si128(data[1], mask0); - key[2].xmm =3D _mm_and_si128(data[2], mask0); - key[3].xmm =3D _mm_and_si128(data[3], mask0); - key[4].xmm =3D _mm_and_si128(data[4], mask0); - key[5].xmm =3D _mm_and_si128(data[5], mask0); - key[6].xmm =3D _mm_and_si128(data[6], mask0); - key[7].xmm =3D _mm_and_si128(data[7], mask0); + key[0].xmm =3D _mm_and_si128(data[0], mask0.x); + key[1].xmm =3D _mm_and_si128(data[1], mask0.x); + key[2].xmm =3D _mm_and_si128(data[2], mask0.x); + key[3].xmm =3D _mm_and_si128(data[3], mask0.x); + key[4].xmm =3D _mm_and_si128(data[4], mask0.x); + key[5].xmm =3D _mm_and_si128(data[5], mask0.x); + key[6].xmm =3D _mm_and_si128(data[6], mask0.x); + key[7].xmm =3D _mm_and_si128(data[7], mask0.x); =20 const void *key_array[8] =3D {&key[0], &key[1], &key[2], &key[3], &key[4], &key[5], &key[6], &key[7]}; @@ -175,14 +175,14 @@ em_get_dst_port_ipv6x8(struct lcore_conf *qconf, stru= ct rte_mbuf *m[8], int32_t ret[8]; union ipv6_5tuple_host key[8]; =20 - get_ipv6_5tuple(m[0], mask1, mask2, &key[0]); - get_ipv6_5tuple(m[1], mask1, mask2, &key[1]); - get_ipv6_5tuple(m[2], mask1, mask2, &key[2]); - get_ipv6_5tuple(m[3], mask1, mask2, &key[3]); - get_ipv6_5tuple(m[4], mask1, mask2, &key[4]); - get_ipv6_5tuple(m[5], mask1, mask2, &key[5]); - get_ipv6_5tuple(m[6], mask1, mask2, &key[6]); - get_ipv6_5tuple(m[7], mask1, mask2, &key[7]); + get_ipv6_5tuple(m[0], mask1.x, mask2.x, &key[0]); + get_ipv6_5tuple(m[1], mask1.x, mask2.x, &key[1]); + get_ipv6_5tuple(m[2], mask1.x, mask2.x, &key[2]); + get_ipv6_5tuple(m[3], mask1.x, mask2.x, &key[3]); + get_ipv6_5tuple(m[4], mask1.x, mask2.x, &key[4]); + get_ipv6_5tuple(m[5], mask1.x, mask2.x, &key[5]); + get_ipv6_5tuple(m[6], mask1.x, mask2.x, &key[6]); + get_ipv6_5tuple(m[7], mask1.x, mask2.x, &key[7]); =20 const void *key_array[8] =3D {&key[0], &key[1], &key[2], &key[3], &key[4], &key[5], &key[6], &key[7]}; Would you like me to re-post the patch? Thanks Maciej