From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0075.outbound.protection.outlook.com [104.47.1.75]) by dpdk.org (Postfix) with ESMTP id 9D2D11E34A for ; Mon, 11 Jun 2018 06:05:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tyR41PySRctUCvo+E+w/rHcmqg4f+KjuBAPk7ipKmFY=; b=IBh4a/BcKfU4iimuj8Bfen/WiZZcCM6UlZeDeOOOQVnIBMHHdclipbqjwTwt1Sdo18/YF1xQEkQguDdtIGTjzKSom7azdxEp+uSPetpfBQhKusRdpM0uL8zyJ7QAdEarq5mSCVDuZJkHbepb7XjQwyN77DYNPTru0xki/3fQLCs= Received: from VI1PR0401MB1774.eurprd04.prod.outlook.com (10.165.234.148) by VI1PR0401MB2432.eurprd04.prod.outlook.com (10.169.134.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.17; Mon, 11 Jun 2018 04:05:26 +0000 Received: from VI1PR0401MB1774.eurprd04.prod.outlook.com ([fe80::3182:c99e:63d6:7dcc]) by VI1PR0401MB1774.eurprd04.prod.outlook.com ([fe80::3182:c99e:63d6:7dcc%3]) with mapi id 15.20.0841.019; Mon, 11 Jun 2018 04:05:26 +0000 From: Sachin Saxena To: Jerin Jacob , Hemant Agrawal CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] mk: change TLS model for ARMv8 and DPAA machine Thread-Index: AQHT/JdZyIIY7fpNJ0OLS5pCyUZt/6RZXSOAgAEZCDA= Date: Mon, 11 Jun 2018 04:05:26 +0000 Message-ID: References: <1528180425-27937-1-git-send-email-hemant.agrawal@nxp.com> <20180610110700.GA6990@jerin> In-Reply-To: <20180610110700.GA6990@jerin> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sachin.saxena@nxp.com; x-originating-ip: [14.142.187.166] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0401MB2432; 7:+P158ye4ItXwiOg49U+rige1dWg4TZ5hC0zWD5TPfKo1m7K+4B7gSzhrnfISokr/gHgWtnu8uSmLAAPXUNGhk7WFQs6tF7TSsoIgpIioKk0tq8BLXZitkPONGwVhER61rF5z/VKrIlQsqTAulSkHylWKzX5jhHpyaKJtDpqjRgA+05baB4JkKEaF23dDStbVXQ+ZJR1va3McecX5vf7eGbSzj5s+6HObIZE46NpB6klx+c42I+Fmc6Nn6kSaouuW x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0401MB2432; x-ms-traffictypediagnostic: VI1PR0401MB2432: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(185117386973197); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0401MB2432; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0401MB2432; x-forefront-prvs: 070092A9D3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(346002)(366004)(39860400002)(39380400002)(57704003)(189003)(199004)(13464003)(76176011)(59450400001)(186003)(102836004)(55236004)(5250100002)(44832011)(99286004)(486006)(476003)(2906002)(11346002)(446003)(316002)(8676002)(53936002)(110136005)(74316002)(229853002)(305945005)(9686003)(3280700002)(66066001)(6436002)(8936002)(106356001)(6246003)(7736002)(4326008)(14454004)(25786009)(86362001)(2900100001)(68736007)(3660700001)(33656002)(81166006)(81156014)(105586002)(6116002)(3846002)(55016002)(7696005)(26005)(97736004)(6636002)(478600001)(6506007)(5660300001)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0401MB2432; H:VI1PR0401MB1774.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 49CpFO28ICaYNNVoQltF3KroQucuADuZy0ZdPReC96SEH9rpJdrbQlQKc0VgNlk3GLrpg1EIj1NZV3IVyjKnIIfKJYNmjbQz6i1N/etEv7BsHreRZtktFRKw+93zc8Jcj+E9SOxFDPdq3qFJggdRv2No1ylkSPHmSRTjddBl4m722EEUlMOF85f9rDfM40xx spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: bf0fd574-80bc-4149-c38c-08d5cf509015 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: bf0fd574-80bc-4149-c38c-08d5cf509015 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2018 04:05:26.3065 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2432 X-Mailman-Approved-At: Wed, 13 Jun 2018 09:49:01 +0200 Subject: Re: [dpdk-dev] [PATCH] mk: change TLS model for ARMv8 and DPAA machine 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: Mon, 11 Jun 2018 04:05:28 -0000 > -----Original Message----- > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > Sent: Sunday, June 10, 2018 4:37 PM > To: Hemant Agrawal > Cc: dev@dpdk.org; Sachin Saxena > Subject: Re: [dpdk-dev] [PATCH] mk: change TLS model for ARMv8 and DPAA > machine >=20 > -----Original Message----- > > Date: Tue, 5 Jun 2018 12:03:45 +0530 > > From: Hemant Agrawal > > To: dev@dpdk.org > > CC: Sachin Saxena > > Subject: [dpdk-dev] [PATCH] mk: change TLS model for ARMv8 and DPAA > > machine > > X-Mailer: git-send-email 2.7.4 > > > > From: Sachin Saxena > > > > Random corruptions observed on ARM platfoms with using the dpdk > > library in shared mode with VPP software (plugin). > > > > sing traditional TLS scheme resolved the issue. > > > > Tested with VPP with DPDK as a plugin. > > > > Signed-off-by: Sachin Saxena > > --- > > mk/machine/armv8a/rte.vars.mk | 3 +++ > > mk/machine/dpaa/rte.vars.mk | 3 +++ > > mk/machine/dpaa2/rte.vars.mk | 3 +++ > > 3 files changed, 9 insertions(+) > > > > diff --git a/mk/machine/armv8a/rte.vars.mk > > b/mk/machine/armv8a/rte.vars.mk index 8252efb..6897cd6 100644 > > --- a/mk/machine/armv8a/rte.vars.mk > > +++ b/mk/machine/armv8a/rte.vars.mk > > @@ -29,3 +29,6 @@ > > # CPU_ASFLAGS =3D > > > > MACHINE_CFLAGS +=3D -march=3Darmv8-a+crc+crypto > > + > > +# To avoid TLS corruption issue. > > +MACHINE_CFLAGS +=3D -mtls-dialect=3Dtrad >=20 > This issue is not reproducible on Cavium ARMv8 platforms. Just wondering, > Do we need to change default ARMv8 config? [Sachin Saxena] The issue is currently visible On NXP platforms with VPP-d= pdk solution only. Similar behavior like random crashes or initialization f= ailures have been seen by Cavium guys on VPP but they are still investigati= ng whether the issues are related to TLS corruption. Also, issue will not be there with statically linked dpdk applications >=20 > The GNU (descriptor) dialect for TLS is the default has been since for a = while > on aarch64. [Sachin Saxena] I agree but this model only applies to Shared mode compilat= ion. As per my knowledge, the "initial-exec" model is default for static co= mpilation or when -fPIC is not used. For shared dpdk or when -fPIC is used,= the default is "global-dynamics" and tls-dialect=3Ddesc. >=20 > I think, it will be mostly a glibc issue with your SDK based toolchain. > Are you able to reproduce this issue with Linaro toolchain + standard OS > distribution environments? if so, could you please share more details. [Sachin Saxena] Yes, issue is happening with both SDK & Linaro 7.2 toolchai= n. >=20 > I am only concerned about, any performance issue with traditional tls dia= lect > model vs descriptor dialect. [Sachin Saxena] No performance impact is expected for statically build dpdk= . For shared mode, minor impact is expected but performance analysis is yet= to be done. The Fix is suggested because right now it is functionally brok= en with VPP. >=20 > I think, we have two options, > 1) If you can identify if it is due a specific glibc version then we coul= d detect > at runtime > 2) In a worst case, it can be a conditional compilation option. >=20 > /Jerin