From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0044.outbound.protection.outlook.com [104.47.2.44]) by dpdk.org (Postfix) with ESMTP id B27172BA1 for ; Tue, 12 Jul 2016 06:11:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coriant.onmicrosoft.com; s=selector1-coriant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8v7pB9dJXDPar6U+AYxXnPBv9hwz3Z/DCWxcRvUhdsA=; b=i/QldN/7irBGoOMqDJoUEOx61MSMo8CvhT+s9UIvh+UhWVlTChLs5SL8nZAF8Ogo0sRXC8dU1KA76E8UOCBUs9UKexgPCYe4XXbSLPt3Q2o5QwxP0gjZk299e0dlsjF40CYIq3q0UPGhc88zL2sujhuHbezil+yivZY9p5cWcQ4= Received: from HE1PR04MB1337.eurprd04.prod.outlook.com (10.163.175.23) by HE1PR04MB1338.eurprd04.prod.outlook.com (10.163.175.24) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 12 Jul 2016 04:11:00 +0000 Received: from HE1PR04MB1337.eurprd04.prod.outlook.com ([10.163.175.23]) by HE1PR04MB1337.eurprd04.prod.outlook.com ([10.163.175.23]) with mapi id 15.01.0539.018; Tue, 12 Jul 2016 04:11:00 +0000 From: "Kuusisaari, Juhamatti" To: Olivier Matz , "Ananyev, Konstantin" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] lib: move rte_ring read barrier to correct location Thread-Index: AQHR22kLySYRVPuveEWjdB+Qttm0zaATKZiw Date: Tue, 12 Jul 2016 04:10:59 +0000 Message-ID: References: <20160711102055.14855-1-juhamatti.kuusisaari@coriant.com> <2601191342CEEE43887BDE71AB97725836B7C858@irsmsx105.ger.corp.intel.com> <5837bceb-070e-76d4-d548-8d5e9f1cce32@6wind.com> In-Reply-To: <5837bceb-070e-76d4-d548-8d5e9f1cce32@6wind.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Juhamatti.Kuusisaari@coriant.com; x-originating-ip: [138.111.130.175] x-ms-office365-filtering-correlation-id: bf7c71d4-f81d-4ef8-d59f-08d3aa0a8841 x-microsoft-exchange-diagnostics: 1; HE1PR04MB1338; 6:o9PUlQ2BjPwW6l/vr5QLeRLD/yVcG8G67JyvZxeq0lByxkUXDtfOCwWsC8dXR1TLvH0Acmcc5Q7HvE/vat1iMdw/r7g+L8G/P2Z/8EXb4KZYXKJZIOOtw5SNf0L3ChAqQeaFOIzn3kQxBlJ6oVTa8tbsP6Q0vUlG+2JrGuVCf+OIw/RKxtwRtPFGQlkpuFMBU6BqgTu81ECOeHlyc5mxwRQjkddzNcVwD8ABvtpzRKGoLIEORXw6X+VzrTb5WgbERh6/gTsMYtItZyfsCwpj7SBXOlE6WzAML3Ff83bCxvIUYKmMWS+QbQE5T+7q8k27Xwj0zemzHta1ggXbfqLH3Q==; 5:OdRV5w25yoFMxzmtJAr/CmI1CNJ+AU9aiurBHcbdV/xlnyYj/qf0s5OnXwRIvSuXQ5a3FK4Tgjyn22c9tL8jb0c1F3ytf3CkNBqOKvW6AwJaxizVOsqDo6V/2MobHhkBu9e7FEZDIdDbf16bxsBB/g==; 24:XX0ORinoLVfxpdqnC0lhSuFTeJQ9M5pvXu3NlGsEfX2jWMICSZlgx9TRMqVGe6Ww0KiBprzLGNJSiusDhpiX/IN4KVhm031sDvezL6a48SM=; 7:nl/Wtj1DwOOyBVOw+hbemzi5SBVDQ75nGkhpLbEME+6ap+Tg4ISOj05qmUhD/DQiXAV2JVGiru39qgHzxJ+7L/0y5k1BD1f38J4sY8F55KfVdyMzwWgUTQWHVHS3y0fr77Z6jSu/YWPPJZhbNJxrzX3uW8vUll0hBNJyQQYOGWzVLMNYFH42t/N4cZa++o1UirgdbOmGRSkaypxKgIVKHeXFvfOA7OLouv+m/oIX/gm9Av7mQLi9F+FiuZrfOiml x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1338; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:HE1PR04MB1338; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1338; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(13464003)(189002)(199003)(377454003)(2906002)(2501003)(8676002)(92566002)(19580395003)(68736007)(107886002)(77096005)(189998001)(106356001)(33656002)(106116001)(19580405001)(7736002)(3846002)(102836003)(6116002)(3660700001)(305945005)(7696003)(5003600100003)(7846002)(5002640100001)(15395725005)(8936002)(74316002)(76576001)(87936001)(3280700002)(122556002)(5001770100001)(586003)(9686002)(97736004)(15975445007)(2950100001)(2900100001)(81166006)(81156014)(101416001)(66066001)(93886004)(54356999)(76176999)(86362001)(50986999)(105586002)(11100500001)(10400500002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1338; H:HE1PR04MB1337.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: coriant.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: coriant.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 04:11:00.0281 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 76595477-907e-4695-988b-a6b39087332d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1338 Subject: Re: [dpdk-dev] [PATCH] lib: move rte_ring read barrier to correct location 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, 12 Jul 2016 04:11:02 -0000 Hello, > >>> -----Original Message----- > >>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Juhamatti > >>> Kuusisaari > >>> Sent: Monday, July 11, 2016 11:21 AM > >>> To: dev@dpdk.org > >>> Subject: [dpdk-dev] [PATCH] lib: move rte_ring read barrier to > >>> correct location > >>> > >>> Fix the location of the rte_ring data dependency read barrier. > >>> It needs to be called before accessing indexed data to ensure that > >>> the data itself is guaranteed to be correctly updated. > >>> > >>> See more details at kernel/Documentation/memory-barriers.txt > >>> section 'Data dependency barriers'. > >> > >> > >> Any explanation why? > >> From my point smp_rmb()s are on the proper places here :) Konstantin > > > > The problem here is that on a weak memory model system the CPU is > > allowed to load the address data out-of-order in advance. > > If the read barrier is after the DEQUEUE, you might end up having the > > old data there on a race situation when the buffer is continuously full= . > > Having it before the DEQUEUE guarantees that the load is not done in > > advance. > > > > On Intel, it should not matter due to different memory model, so this > > is limited to weak memory model systems. >=20 >=20 > I agree with Juhamatti. To me, the reading of consumer_head must occur > before the reading of objects ptrs. >=20 > That was the case before, and this is something I already noticed when I = sent > that mail: > http://dpdk.org/ml/archives/dev/2014-March/001742.html >=20 > At that time, only Intel CPUs were supported, so it did not make any > difference. >=20 > Juhamatti, do you have a setup where you can trigger the issue or is it > something you've seen by code review? This was found on a code review when we investigated a problem that could h= ave=20 caused issues that this kind of bug would introduce. I suppose one would be= =20 able to see this with very short ring queue lengths and high load, but it d= epends on the HW used of course too.=20 BR, -- Juhamatti > Thanks, > Olivier