From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40086.outbound.protection.outlook.com [40.107.4.86]) by dpdk.org (Postfix) with ESMTP id B859D1B673 for ; Fri, 3 Nov 2017 04:22:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sd4vRzdBdr/2F9DrG/GJ1aTKsGWYHhyJ0okr2khhcik=; b=ODrz4CoQk4iiku1ZEW8Ort2ZKpNKpLbvuOx84+hyZ4tRE6ZYF0Bk0b+wC94h3bxtGYElhf0Pnw/j0S5HBphNwjM07Ny9baz2iduHntlfqmHVTl6LeHvMmg/7f51/rX8HmS8lUs6L4ZGN//MQS8K3dStw5TR/c9OCcA/nT8EgYPA= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jianbo.Liu@arm.com; Received: from arm.com (113.29.88.7) by AM5PR0801MB1346.eurprd08.prod.outlook.com (2603:10a6:203:1f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Fri, 3 Nov 2017 03:22:50 +0000 Date: Fri, 3 Nov 2017 11:21:43 +0800 From: "Jianbo.Liu@arm.com" To: "Ananyev, Konstantin" Cc: Guduri Prathyusha , "dev@dpdk.org" , "guduriprathyusha@gmail.com" , "Kantecki, Tomasz" Message-ID: <20171103032141.GA6518@arm.com> References: <20171102143114.24380-1-gprathyusha@caviumnetworks.com> <2601191342CEEE43887BDE71AB9772585FAB87F0@irsmsx105.ger.corp.intel.com> <20171102153327.GA24586@cavium.com> <2601191342CEEE43887BDE71AB9772585FAB884B@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB9772585FAB884B@irsmsx105.ger.corp.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [113.29.88.7] X-ClientProxiedBy: HK2PR04CA0081.apcprd04.prod.outlook.com (2603:1096:202:15::25) To AM5PR0801MB1346.eurprd08.prod.outlook.com (2603:10a6:203:1f::12) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bdf220cc-c8c8-414b-facd-08d5226a2ad5 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM5PR0801MB1346; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0801MB1346; 3:GMobNkfhWv4Rh3pr51ZpxEYpxt0Sh5rFrfd/fG4HBKNIlwQ0n8RERRkOLmpBMEsu9LOhgYgBP4kwxminj59OBPJ5PgUM7gWbaOUOqjOSifuoSRgCjLBrMbGdhMiGZQV8WFIHzjHKAEfkgQ4Dxe6LeOLoBOFv2vRBJmggabZ1NC0eD3QYWBOSepO0//XVxfEVDFGHKJD/RARwpsvmip5yhWrfK0Uo1Ulv89BKEgvmYfsz7ITQD4e5ymTbrhyYXB7e; 25:CaS/yk/YBrZ9PS2Gth5g42VQqmiL3l6s6SReYxB7u4CxTKktXeZn/pVhSD8GcbO17Ud6jQn0tUdh6FEe0C2yTO/kVhhOSWR+o8ElUjsWkrYadImBkqfwg+oLaOC5wMCmbb0DSsVtVz0CjuGADT5peLVi9py1G+jZEWQplsoFL1sjwiZZkewIoads7gj9EqRyzul9iSQhz0HRSKbtPKYiYjwwmTclvp957VRl6d4LCFLqTWn4kft8XMVL6f7Wbdo4vJxWb3e5Jz+fMzxoHzekq9ZARiC/9sdfSOD6ZlfjTexQwVwudlZQlTPXSLCYn0xLFGWcrNWCGuP8Ykja1/B0CA==; 31:zEsCoWLamnnmOvROSyYMCgO7aJSAq7yt76jnQnJydRCewvupnMv6BUcsLPivhNBz0slSVT75cCFgGnHWoe77hq1bU1TKo3ykgEY48cB+0CA7r0i5ComYHk+ZN6x7r9vAjiHy7qDU5y2/Lm7AqL7TCCg5TQX4c2EjX0GKylQmxoEV0mhDf4BkB/ZQmLqGf4p9D5C2RsfHxv6G8WBs+6RClKbx7gQevIXJRi8ao8B4698= X-MS-TrafficTypeDiagnostic: AM5PR0801MB1346: Content-Transfer-Encoding: quoted-printable X-Microsoft-Exchange-Diagnostics: 1; AM5PR0801MB1346; 20:tdhZG0N2Abmtu57sHnW9FXWho8ic7hhrAZXNvir43eme3C9/+QUgASCMw2ovIL+CSU3z/FpWzZZVLcvrpElNHN7W1zv0BBWDqq2EQAHBdNUudfHLroJnkPdhgcmzCJxfhmk7kwFQs6MqhpwFpNsc2rHEnRDDv4Y0pXmnO6qtKFCeW28Lt/+V807sorU4tprEIf1UxsgI3yM/7z/qu3OWdvtHCb2y8rg2Um7YMvZyjciR7211m9NqclxPGrUcx64BSC+MUvug5xOdAlV726rDK1rQ5Oror84WNuL4s/Kdew5ZBYd8diPj5SN/s7+Iz4y5dPkUMXr4CVigRFu/IWIjy2P+tvdyYtqavR6kAuVwlrpROWF6wfAzkAV0/96BaMK/FgQeIV3nnWeqhS+qgS0CLuSzovirmLGYa9wlWEVP6PUqogHut03dmr1m+KgHBKmH5ARZoYX6l1oQUWhqpgzsdUs6kc3UAVJy4LKrNnq4A2xREpQkkiU6NufgJSQM9Mb2; 4:GX0TOIwqc/krbI2+SyGpixoIaIFFBfMRzBGQTXuPOYqKxKG/k/5crUSnDLhjANQGYUXhaLB5ZrALea0R8aHGUa02HpU48CeJ4wQnP0hNvPZsmI2jkKlfnKuS+pOtqd6e7nLdtUZ8gzsj8wizkt8BPWKb8dKDVCyq04YnQzyjPZ9GbjWZGU9QenKdVa2CzwNZQUAk2c+K5b3Qdihk2PI8PrR8I5rHTFUmUVZkPs9m6S9BwY/8eV3Ou7zRbaPpS6No+2mXy3JNt4ywNUipcRTiQ9CODfTYP5FROJMGFfpgCmAUS/w2khI1PcFStYXtqK53Fvj8CrWpSTHp5biAeKE1FjmpMD82f7bSTFfv8U8rMDE= X-Exchange-Antispam-Report-Test: UriScan:(180628864354917)(228905959029699); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(3231021)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123558100)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0801MB1346; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0801MB1346; X-Forefront-PRVS: 0480A51D4A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(39860400002)(376002)(40434004)(24454002)(199003)(13464003)(189002)(6246003)(53546010)(2906002)(16526018)(4326008)(39060400002)(76176999)(54356999)(50986999)(316002)(58126008)(54906003)(93886005)(105586002)(68736007)(33656002)(2950100002)(6916009)(106356001)(101416001)(6666003)(83506002)(21086003)(6116002)(36756003)(5660300001)(3846002)(1076002)(229853002)(478600001)(97736004)(47776003)(72206003)(189998001)(81156014)(66066001)(25786009)(53936002)(81166006)(8936002)(55016002)(8676002)(86362001)(86582002)(7736002)(8746002)(23676003)(305945005)(5890100001)(50466002)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0801MB1346; H:arm.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA4MDFNQjEzNDY7MjM6dEFScm13TFQ2TFZDWU9PdXJwazQySmUx?= =?utf-8?B?Rnk4WERsTmZqNHMyRFFzNDJIa3haK1ROSWE0V3ByS2JPNnlRb3RUbmZQbDBn?= =?utf-8?B?b3VQdWtPT3R1VlZNZElzdUErbGJjeS9vM3VtMVN2ZzZ2a3lnNEFDaUFoR2Zl?= =?utf-8?B?WXdtOGQwRWFVNkp6K2RocERmZ0trZkYxYU1YckFGd0pLYUdRcndaNzZkZGll?= =?utf-8?B?MWx4ZkZZVGRUVDgvT1Y1VUtLUVN0dGxON21uTEEwOCsvSTJhQ0RwbnJHdXdV?= =?utf-8?B?aVNlci8yRmlMSDV2UDlORFo5K0ZFeUxCbkUzTmxTRUl2Y3c5VEdrU3h4QXRv?= =?utf-8?B?SW9oSU0rMHlRTXRyUC9KbGY0eUh3c2piZHhLSXcxSllwT25rV3Q0ME13ajBJ?= =?utf-8?B?THliNnZkTHJOZmhsem1JRXJzdkpWNnA5ZWpSeEF6MFpQaHU5ZEppRS9NcWtR?= =?utf-8?B?OWxveTI5c01VWXcwVjRUVGEyK3FyL1NuK0JCYXZOSXR5VGlPWldXU3RyNXpN?= =?utf-8?B?TGVpTkZmeUZFUndKelIyZE9HMXRiWFVhUHpzZ2M3bVdQblVINW1BV0hlQ2ha?= =?utf-8?B?a3pleTh3dlpNT2JFQmlkZ3MyOC9MRDc1L1NqcFBBWllPSlZSa2p3MlI0bU1x?= =?utf-8?B?STBxTDZYSktDL3Y5R3E4ams0Z2V3OG9ZRGF3b01GQ2M4dDlnYitFM3U1c2xG?= =?utf-8?B?ODFvbzNSTGkvaFJIZ2tNaGp3cWRKUHpGWkN6OTU0YW5Hd3UwWURFWlBMNG85?= =?utf-8?B?aUJJM1lZdXlBSUo1WjhDUDFRVFNTb2R0N09pV21JNG52OWlENEtSRjMzQTRJ?= =?utf-8?B?dzN5NkxHeXF2d21pQmlRWGF5Qm0rOGNyVFRCZHNwUGNtN1grUW41OEk0QU9n?= =?utf-8?B?SVdZWFVjd3dER2hJR0V4eDJORlNiR2NOenV4ZXBZcHVqcnlsTFQvN25MMHRX?= =?utf-8?B?ak9lcnhKc1pTN0huOTBIY1AxRmFXdEw2blJ5RTZVRXJPcUZpU2E1Zll5WmpU?= =?utf-8?B?aXFMcHN3YlRVT2JucU9SbTJaeXdsRmxSNXdJTlFsQXhxTGdRbE9GbXlMUHRR?= =?utf-8?B?SXRnRmpZL2k2MXlSRnIzbVhqT2FINVFiL1hLSXMxMCtiVFRKbkc2VDdsb0d6?= =?utf-8?B?S0pFQWJlQ3B2cGxnSnB5NGhuVGxHU21teC9yQ3o0NUV6U29GSnhhaFZmbU1S?= =?utf-8?B?S2U2aWwxb2txMzBBeC9YajJ5alY0ZXdvL24yMkduMnpLbUtjVjR0NENrUDBQ?= =?utf-8?B?Y2JGeGlSakhnUkd1Skx4QWNLZnF0Y1ZBNTRwaTNLN3dsVk1kMlBXdEhSU2l3?= =?utf-8?B?blUyQ0IwcEY0U3JVcnJTOTg4UmdlK3Q1TlF3V1RUckF1ampoUFNtMUF1Qmdq?= =?utf-8?B?WGFORlVwUEN2dXBJcXlGeHNranc5ZVJtMGFUWHJSeFFZbW1uQmNSVjNOZ2Np?= =?utf-8?B?QzVmN2VuajVUTFRzRGdpMm9YZ0ZqTXdzeFZpMlZRREJtNGZpdVlSNGNuNk1Y?= =?utf-8?B?TXlmWE1kVUhOeGFTZm9lSVkzNlpRTE9QNlkxL1lTMzRyY0pJYVdtVFpMRlF4?= =?utf-8?B?dEpmdEVwTXpvTmZDdHNlY01Pdzg5dVZDMDk5VGEvMUNnV1pqTW9saVcxeWQ0?= =?utf-8?B?RjEyb3ZTOE80TUgxNzcvczYxZzkxdFhteTB2U0dzbHk3SndudFRIMmNFV3hp?= =?utf-8?B?NFZQNFFMY0g0RGp5RUtwQ0ZNM1RkSThhcXhmOW9XcHR6WCsrQnNxWWcvWEdY?= =?utf-8?B?dk1TNVdIWVBkK1lmeTJqd3ltQ0RGWjBHZEkwMTRXWE50eU13cnFWT1FKQmtB?= =?utf-8?B?ekNlMHB4MUhGRjZEZE1sL0d5V29jOUNlRWJGejZZdVpjU0VvRFQ2OUVtRXdJ?= =?utf-8?Q?or+quDSQdUKwtmMeeJHtXo9ZUbVCp6dvk8?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0801MB1346; 6:pHjB+7wvyi+JgeQLq6cOIkWwnSv9GTLn/s4hJIidgb6EFGnqLFHRC9kkqkHHQc59Tw1tuCNqLFsjiiPnhHK1VTSN1ze3d9fYxpP/3wto0sGPTzEc7qAGqbWKtL2ZmJKK+gN7nA1XzTgEaf5G0SKwpef8gk09Kw9PRpJ0f0/J7EZ+7XP/tMZr+0PWUs3dreeAcG9Zhlsnnnl2wftfPLDFQEUZbG9E62ZgD6kDMKYoTQxFc/Ru6v5jLoMWefNXeFu9LJ5krUrY2eg7YROgv1T2F9oITEy+QvR4coync8+meFKGC+wBjj+NovgvbfFZK0mXTGvgejHfIl+zqCqPqwBCnnBJ3jONm5Lsyyp0jwX5z1w=; 5:4OZND+A+pugdshJCi5BbHRYoFTMNVrdeE49xFrtwojXbC5HFNfsOfh5gd/pEFd1YKZlBvwEaHBQpL+S4iS/lyPUnkRV6Gs+NNVczjXnpOUmQYZQzBDXWbtfyZaoiJwprwe539Eb49StG0oFEjv6wgm69B1tZougouKhLTip3hFg=; 24:YyLY8jLNnM9h3eVAMyNpNFZfxvd9M2IjHT4xztyziCWaerFIC6fEFS3zah1iL6Oy0kpPkM4/k2xU1X5neDDtYCHPoaVoENoey8qEqudkDuo=; 7:KLQqyMJm1tPaseJmHCZrpZk1T8LtQUm8WD2daQKw5UEkWGJEIRFFBdORCLIAW5k1XnoXCrpAxtVeU4rYKBhf7WPZkVSSJcQoAN0pndFp6fW2HntqNgCvEXrz4gmadf6ECizf+ffuYBXZFgPTLfSTjLNPkrWrshnMkW9xYyFYMSg8YDmiXZBjnLBGqKdr/uN9wANd0i4WR1nZHexn34CSSFDQtBv/KZrz/4qlI3JSyp09YzLKyFOjoLKcFyl3xYlq SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Nov 2017 03:22:50.5211 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bdf220cc-c8c8-414b-facd-08d5226a2ad5 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB1346 Subject: Re: [dpdk-dev] [PATCH ] examples/l3fwd: fix aliasing in port grouping 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, 03 Nov 2017 03:22:55 -0000 The 11/02/2017 15:52, Ananyev, Konstantin wrote: > > > > -----Original Message----- > > From: Guduri Prathyusha [mailto:gprathyusha@caviumnetworks.com] > > Sent: Thursday, November 2, 2017 3:34 PM > > To: Ananyev, Konstantin > > Cc: dev@dpdk.org; Jianbo.Liu@arm.com; guduriprathyusha@gmail.com; Kante= cki, Tomasz > > Subject: Re: [dpdk-dev] [PATCH ] examples/l3fwd: fix aliasing in port g= rouping > > > > On Thu, Nov 02, 2017 at 02:46:43PM +0000, Ananyev, Konstantin wrote: > > > Hi, > > Hi > > > > > > > -----Original Message----- > > > > From: Guduri Prathyusha [mailto:gprathyusha@caviumnetworks.com] > > > > Sent: Thursday, November 2, 2017 2:31 PM > > > > To: Kantecki, Tomasz > > > > Cc: Jianbo.Liu@arm.com; guduriprathyusha@gmail.com; Ananyev, Konsta= ntin ; dev@dpdk.org; Guduri > > > > Prathyusha > > > > Subject: [dpdk-dev] [PATCH ] examples/l3fwd: fix aliasing in port g= rouping > > > > > > > > With -f-strict-aliasing enabled by default from -O2, gcc > 5.x give= s May I ask the detail version about the gcc you are using? > > > > undefined behavior in port_groupx4. 'pn' and 'pnum' are two differe= nt > > > > pointers pointing to same chunk of memory and with -f-strict-aliasi= ng the > > > > pointers are assumed to be pointing to different memory and compile= r > > > > reorders instructions that depend on pnum and pn. This breaks port > > > > grouping algorithm. > > > > > > > > This patch eliminates the usage of union and uses memcpy for copyin= g > > > > gptbl[v].pnum to pn. memcpy when applied on built_in constant size = does > > > > not call its library implementation but uses appropriate LD and ST > > > > instructions directly and hence no performance overhead. > > > > > > > > Fixes: 569b290cdb36 ("examples/l3fwd: add NEON implementation") > > > > Fixes: af1694d94bf1 ("examples/l3fwd: fix crash with gcc 5") > > > > Signed-off-by: Guduri Prathyusha > > > > --- > > > > examples/l3fwd/l3fwd_neon.h | 11 +++-------- > > > > examples/l3fwd/l3fwd_sse.h | 11 +++-------- > > > > 2 files changed, 6 insertions(+), 16 deletions(-) > > > > > > > > diff --git a/examples/l3fwd/l3fwd_neon.h b/examples/l3fwd/l3fwd_neo= n.h > > > > index 4bc161394..10a602a04 100644 > > > > --- a/examples/l3fwd/l3fwd_neon.h > > > > +++ b/examples/l3fwd/l3fwd_neon.h > > > > @@ -100,11 +100,6 @@ static inline uint16_t * > > > > port_groupx4(uint16_t pn[FWDSTEP + 1], uint16_t *lp, uint16x8_t dp= 1, > > > > uint16x8_t dp2) > > > > { > > > > - union { > > > > - uint16_t u16[FWDSTEP + 1]; > > > > - uint64_t u64; > > > > - } *pnum =3D (void *)pn; > > > > - > > > > int32_t v; > > > > uint16x8_t mask =3D {1, 2, 4, 8, 0, 0, 0, 0}; > > > > > > > > @@ -117,9 +112,9 @@ port_groupx4(uint16_t pn[FWDSTEP + 1], uint16_t= *lp, uint16x8_t dp1, > > > > > > > > /* if dest port value has changed. */ > > > > if (v !=3D GRPMSK) { > > > > - pnum->u64 =3D gptbl[v].pnum; > > > > - pnum->u16[FWDSTEP] =3D 1; > > > > - lp =3D pnum->u16 + gptbl[v].idx; > > > > + rte_memcpy(pn, &gptbl[v].pnum, sizeof(gptbl[v].pnum= )); > > > > + pn[FWDSTEP] =3D 1; > > > > + lp =3D pn + gptbl[v].idx; > > > > } > > > > > > > > return lp; > > > > diff --git a/examples/l3fwd/l3fwd_sse.h b/examples/l3fwd/l3fwd_sse.= h > > > > index 831760f02..79a71d77e 100644 > > > > --- a/examples/l3fwd/l3fwd_sse.h > > > > +++ b/examples/l3fwd/l3fwd_sse.h > > > > @@ -98,11 +98,6 @@ processx4_step3(struct rte_mbuf *pkt[FWDSTEP], u= int16_t dst_port[FWDSTEP]) > > > > static inline uint16_t * > > > > port_groupx4(uint16_t pn[FWDSTEP + 1], uint16_t *lp, __m128i dp1, = __m128i dp2) > > > > { > > > > - union { > > > > - uint16_t u16[FWDSTEP + 1]; > > > > - uint64_t u64; > > > > - } *pnum =3D (void *)pn; > > > > - > > > > int32_t v; > > > > > > > > dp1 =3D _mm_cmpeq_epi16(dp1, dp2); > > > > @@ -114,9 +109,9 @@ port_groupx4(uint16_t pn[FWDSTEP + 1], uint16_t= *lp, __m128i dp1, __m128i dp2) > > > > > > > > /* if dest port value has changed. */ > > > > if (v !=3D GRPMSK) { > > > > - pnum->u64 =3D gptbl[v].pnum; > > > > - pnum->u16[FWDSTEP] =3D 1; > > > > - lp =3D pnum->u16 + gptbl[v].idx; > > > > + rte_memcpy(pn, &gptbl[v].pnum, sizeof(gptbl[v].pnum= )); > > > > + pn[FWDSTEP] =3D 1; > > > > + lp =3D pn + gptbl[v].idx; > > > > > > Could you explain a bit more here - which exactly instructions were r= eordered > > > and what kind of problems did it cause? > > > Specially on IA? > > > > This issue is observed on ARM since ARM gcc is more aggressive in > > reordering than x86 gcc. > > Ok, then if x86 is not affected why to modify l3fwd_sse.h at all? > Unless there is a reproducible problem with x86 - > my preference would be to keep that file intact. > > > In ARM when v !=3D GRPMSK, the following > > instructions ordering is not guarenteed because of strict aliasing. > > > > lp[0] +=3D gptbl[v].lpv; > > pnum->u64 =3D gptbl[v].pnum; > > pnum->u16[FWDSTEP] =3D 1; > > lp =3D pnum->u16 + gptbl[v].idx; > > Ok, so what in particular is reordered by the compiler: > > lp[0] +=3D gptbl[v].lpv; (1) > pnum->u64 =3D gptbl[v].pnum; (2) > pnum->u16[FWDSTEP] =3D 1; (3) > lp =3D pnum->u16 + gptbl[v].idx; (4) > > (2) and (3)? > If so I am not sure how it could be a problem: > they do stores to the different locations. > (1) and (4) as I can see shouldn't be reordered. > Anyway - if you think this a compiler reordering issue, > then adding rte_compiler_barrier() should fix the issue, right? Agree. > > > > > That results in wrong lp[0] updation. > > memcpy in this case will avoid this problem. > > > > > In any case I don't think using rte_memcpy is a good thing to use her= e: > > > it is a huge inline function - way too much to copy just 64 bit varia= ble. > > > > I agree that rte_memcpy is overhead in this case but how about using > > memcpy that will not use library implementation if the size is constant= . > > memcpy with constant size uses built_in_memcpy that does not add > > performance overhead. > > On x86 rte_memcpy() doesn't call libc memcpy() at all - it is a separate = function: > ib/librte_eal/common/include/arch/x86/rte_memcpy.h > > > > > Thoughts? > > As I said - if x86 is not affected - please keep l3fwd_sse.h intact. > If it does (still not sure how) - check would compiler barrier help here. > Konstantin > -- IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you.