From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id E07DFA0547; Sun, 28 Mar 2021 03:00:52 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 681CD40042; Sun, 28 Mar 2021 03:00:52 +0200 (CEST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80082.outbound.protection.outlook.com [40.107.8.82]) by mails.dpdk.org (Postfix) with ESMTP id A876340040; Sun, 28 Mar 2021 03:00:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lcDZvdOAqnUX80dQpMge+2BAlAwda4jNrDAV+awBylo=; b=L6RWan6yx+Ql9vbEfZBYTuaY91+mKe0T8gCpwTqLWBUue4TOwwuBHmwGO+i+pwNpIyh8qc06WciKI8P5k1Dlk+V9ta3OHpTQ1YaMhB1w7TJuX+1rnjRBmCwOmjq65/EIIgir+LDrssElG4n9kSmUe+zjzYsDNASU+XbjvoC+SRo= Received: from AM6PR04CA0033.eurprd04.prod.outlook.com (2603:10a6:20b:92::46) by AM6PR08MB3575.eurprd08.prod.outlook.com (2603:10a6:20b:48::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.26; Sun, 28 Mar 2021 01:00:37 +0000 Received: from VE1EUR03FT037.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:92:cafe::5e) by AM6PR04CA0033.outlook.office365.com (2603:10a6:20b:92::46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.25 via Frontend Transport; Sun, 28 Mar 2021 01:00:36 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dpdk.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dpdk.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT037.mail.protection.outlook.com (10.152.19.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.25 via Frontend Transport; Sun, 28 Mar 2021 01:00:36 +0000 Received: ("Tessian outbound 24fdfdedd45c:v89"); Sun, 28 Mar 2021 01:00:35 +0000 X-CR-MTA-TID: 64aa7808 Received: from 964c90c34ace.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 9271F3CF-6987-4B19-A59C-19738B2BF358.1; Sun, 28 Mar 2021 01:00:30 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 964c90c34ace.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Sun, 28 Mar 2021 01:00:29 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oR3pEYvaDlAiMcngonNlLnwKMT8h6n/+f1Zo9vE9CzDTrRO0XvCs1sJGz8IrADCTxUIdbBsSSYVmrhTyFSVM6nhn+zVN2lQci9iqy/8Qj04Oow108b7xKs0YIWbUieojHULz4jfqx/kWYayfECOjbDx3e5MV83TbJI11Miy6JafNautEGv5eihFwy5gK2A8wfDTzL56AmMRMrrtC3R0exknkCUR9cW3lgjWPTXvcEEzLVBCNpXfgR8PNNrZREu1FYU2oeDyRB+q8091ueXM788BqVR3slLCeQhZ/8ZnQVYkVuTRSoE7R4+7JI8DIo5XJXh3fpdmx6iG+gYsvZrUYew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lcDZvdOAqnUX80dQpMge+2BAlAwda4jNrDAV+awBylo=; b=EHKW3avU3RSTHKYvktfmTNAtzSes3lGLnfAZipn0umwfYRFJzQCugZVmj7Nyk/2/qMvxVezrmibJAyKkuNsHhLjArCzsXKkmaMs2jgYTEElzP/EbfiytOP4gZPno++8otWE8XOW8Ns1AsaSt91Pfs9WVZD7FGWuBZWxvmMs7ysciqCd+MxbDJ23nXCt5fOU/F2ZSA4in0DXMK64yL7bt6jO/MZwgUgAEXWsw8AAPXesowHRKmKZ2q1oGKBQFBUmbmitgsU2v/pLSqJwMxmsXY7CyBNNZVALDWfz8JfCfqfk/jmQlWFleRr+jMpoMqcVsW7aqQrZYhB11MqyZrcrIjQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lcDZvdOAqnUX80dQpMge+2BAlAwda4jNrDAV+awBylo=; b=L6RWan6yx+Ql9vbEfZBYTuaY91+mKe0T8gCpwTqLWBUue4TOwwuBHmwGO+i+pwNpIyh8qc06WciKI8P5k1Dlk+V9ta3OHpTQ1YaMhB1w7TJuX+1rnjRBmCwOmjq65/EIIgir+LDrssElG4n9kSmUe+zjzYsDNASU+XbjvoC+SRo= Received: from DBAPR08MB5814.eurprd08.prod.outlook.com (2603:10a6:10:1b1::6) by DBBPR08MB4631.eurprd08.prod.outlook.com (2603:10a6:10:df::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.29; Sun, 28 Mar 2021 01:00:17 +0000 Received: from DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::2994:a01e:2de:f94e]) by DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::2994:a01e:2de:f94e%7]) with mapi id 15.20.3977.032; Sun, 28 Mar 2021 01:00:17 +0000 From: Honnappa Nagarahalli To: "thomas@monjalon.net" , Takeshi Yoshimura CC: "stable@dpdk.org" , "dev@dpdk.org" , "olivier.matz@6wind.com" , "chaozhu@linux.vnet.ibm.com" , "konstantin.ananyev@intel.com" , Jerin Jacob , nd , nd Thread-Topic: [dpdk-stable] [dpdk-dev] [PATCH] rte_ring: fix racy dequeue/enqueue in ppc64 Thread-Index: AQHXIPcALzOXzdGicU6lOvSAVPndEaqYl2Tw Date: Sun, 28 Mar 2021 01:00:17 +0000 Message-ID: References: <20180712024414.4756-1-t.yoshimura8869@gmail.com> <20180717033410.GA3344@jerin> <7532216.RsKJNViV3k@thomas> In-Reply-To: <7532216.RsKJNViV3k@thomas> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 690DEE1753746541A707EECFDB9DC0B7.0 x-checkrecipientchecked: true Authentication-Results-Original: monjalon.net; dkim=none (message not signed) header.d=none; monjalon.net; dmarc=none action=none header.from=arm.com; x-originating-ip: [107.77.219.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 873a4a43-56ff-47f4-9280-08d8f184e5cb x-ms-traffictypediagnostic: DBBPR08MB4631:|AM6PR08MB3575: x-ld-processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: wKNGE+5Qg9SFQBWhjM/eR2NEPlfqVYaRmwo7UdihiujTk3pTus56OcPIYeeaS8OhsnH1rkLQu35fWPrRH/1onkleqvwQ8Pw5RAX6AM9BQLAaKJSgMPps3ArBx2FK6Yw0QRIU/HkVPx7D4yeLX+MLNu/LSFqVeDWrx8qSbPY3bdnUy7Dyu0m4aNKy2K3xUeI4nL/Cu6rrt3qiez+WhsZV45ojCXR9sfJSJ8yOvU7scps8tH0O20Jszsetoy8Hs/sxA5G9MtyLgoJcioblA9wumELK8LtWz04ifORnTj7/mZKlDje4tN+ilEfbkZVTWVzViZoNiNhR+bjr76FBFNq6SQyWHr1+dXS4huTVKpFDqIFCW0UGhfwPRwDCZ4pICN7i4eWjfQpQO92cFyarIZKVFf1sINXGqjrb2Kh0ieIUT6/C4NM2bQ9mpTrLer01pPmDsaVsJH3qkYh3LZJ7T03oSkCQbVOQVVqy4eoktPTS9fQhgqZU9Br/g8miJBvLcb5DctcTbvNVd9lOmCO/RvFBvZP/n8zSk43b1EXQIFe+5gKp7t8H64lH+jX/lP4ERI5ToHanZws1PK0Xc50qH84XY//au9O4Ic45FcPf0XOgjXGNiQ2uK9XgieFcAQaCi7GKcYSsrHUDwGa14WTtOd+n97cHGpMp+t+MtRjMcRZIWsUWAU6NVtJ8ZuxBzAmbXGY40nx4oQwIZ+Q2MstIVoGGR/ODqmfc3xOtqCECJ8XSZTIYWQM1nmCckh2TJ57lzHkR X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBAPR08MB5814.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(396003)(366004)(136003)(39850400004)(8676002)(33656002)(76116006)(66446008)(66946007)(83380400001)(2906002)(26005)(6506007)(38100700001)(55016002)(316002)(54906003)(186003)(5660300002)(4326008)(86362001)(71200400001)(66556008)(52536014)(7696005)(64756008)(478600001)(66476007)(9686003)(110136005)(966005)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?jgyFEsrkV13TQtjo2cBRy9FvBYwqu8DmRhNlL25mOpmEBFVbY6VwKx3eHQ4R?= =?us-ascii?Q?LyFQCIxb1eS+93MqsDx6ZKK1oOxey3nV0LuklFXOmmFLq6/4/8oDSIDh6vzw?= =?us-ascii?Q?tRF6Uzv6rYPU9i28eePe1NKLx8UnLfRy5/M/xxK7w7z+vZ32mjIugxiOIiT2?= =?us-ascii?Q?m/nrvov5puy9m1QRBfo9qjda0egBdgsgcICZ4DaVkHaeV6CJphEFoJB+64HZ?= =?us-ascii?Q?7rtjsSDicJ4Laz4ZWaXHyWJvZnPzMbkKOuT0AyjoJ0mI3lFbEU04LHD5hP9M?= =?us-ascii?Q?rzjy6V/iwZL/0gxmpumwIMN4LrSJE91pPtuw+FsP56N8E0ibvdzHez9jAs5o?= =?us-ascii?Q?oqSUrFmobw0bhYjZjB+1uXtwwmpk4HLH8O6zXpJVNNN7f1Vfzm0kCSu9jjRm?= =?us-ascii?Q?v8UZUG2Lk3pVgOUzbU7ciGAf4QPBD8ixHxtZyLzJCdFhq0zjscEfusz+2QWs?= =?us-ascii?Q?HTd1AFTbrTIZz0eYs3ZwLsbFy5NcLjcRK0N4XYr8mWZyvJ7oHxYsL8f/o6tV?= =?us-ascii?Q?BLayccL465/OwaZRD6JhYKtn5+uoP38mgzrMIK+DKehap2hfZEDk6uhqEwMR?= =?us-ascii?Q?MWw9ns6GYSgRCkDkWj8AL53qsAvagDdxHieKlcxaXpyOVX6/UBYzotOu4EJo?= =?us-ascii?Q?d5C69agQutLDF+19d85IVU/NlqsZgrpP47nBEG2UAa8mmqEfbvZBShBVP/Sz?= =?us-ascii?Q?JW7p5ZS9oaugz5NFxXOwCpF46+mli85F2GtHUmuqKIJQ5iO+ssgCcyrWyXJR?= =?us-ascii?Q?ThjAP0tHtnkJIo+dA6Lyp602BqyOSE+y8drED1aHjT8Gu64HXhLWs6CoshQT?= =?us-ascii?Q?5Cq8ZMxL1LHL60TRUye1xsQcZL4p5IQ/tELiMgFolFIcj9Suyucw0YEl4jYa?= =?us-ascii?Q?bIBmleEb/mvNAh2q8+fyFqPzG7dgzJRZN0eGGsG3pN5vZW0wIAw+J8wrxcw8?= =?us-ascii?Q?oc7J9TaBEdB4NB3Jl2qOVQTVMA//G3XtPyZdWpnbUt38dgWD+WrqJLA31dKN?= =?us-ascii?Q?Ta6N5jBxp979E3M01KUqYnKndkhohufRNQmIZeZJbmikTdNDQv0mW+lnCsBP?= =?us-ascii?Q?J/UD+WVW8ywb2TbGO6BJx0IaAkDTwKk/WBSrBMMY0IU1n0Krp5OvA8LVNUW+?= =?us-ascii?Q?YLBb2LY41reWA1BOOKYL1NtMwlWg9Or7b2xjDbOo8LFHsgX8PkRZ0/WYzDyX?= =?us-ascii?Q?xBLBrRKiBuYbseBlenzYpbHAcp4hOpL/dZwpAh1dgfoBLobhtusApcjMpoIT?= =?us-ascii?Q?pLJGyRE6goaPc99iA0PJM4a5siK8TCMTdQhitbig4w2YVzGd77rumRgpzTeB?= =?us-ascii?Q?6Ixm/GLwZbOORa+Bz8KeP+F5?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4631 Original-Authentication-Results: monjalon.net; dkim=none (message not signed) header.d=none; monjalon.net; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT037.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 90f8200c-ae85-4da7-3ab9-08d8f184da6f X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: A+FR4XXijNoSn2lCVEryKbJ3xu3+2idbgyCNlHV9FXQyUusez5iPCUPc80+Oip3FUWeKpuDXJU5RhfIJSzZzn3IbBOuUW8U6IEuJi5TDNHzHsaipC4uNc4KDqy4s2gh4046Jr6034T+tsUptgUa+rG1Ir5sgjmW+jNNlzXDM/ZvMibBeGudCO2RnDMrXoNhBMHHTSINpAwdNoh/jK/wmVIPs+GKbjlA2cyII4Oolw975KPxgnRQan/hQPo6RrVEk78waIjaK29/z3HbxVgfQWpdTgJ122ZtMwHgqDjn4afdflXV7U+XAyLsnPgAJgXxHC7W/vz64/oalL+gsqQh2J1WE2PzvlgRen7z4m3ak2ysJomtvkRh/18mj1Wln0CPhPU7CiEcJ6zllsokJfD4DYecFjAH6HI7gk2ZODNqcx8jQCeCuR8/HpWx8V0YRL94Q6bgfHxFhOXPAs0LPIQgVRtq7vc44qzsFVE/S412E9I/20dfQGODPnCTQBtWVadpAdm5nlrXXgj0Nz/jDAIeHysa80T8GwH5oQOL17EEjZnwRuK+9deRqmIczBQNIRhjDoLAvB1IOAgfbcKGpijfNqOuXm/AczD7lyUTfql1pnML19I7Qa/FvzKqPlyVx1u9Z7KJL3dh3ViDuwrT28jdi8NbLADCuPLs+8RvfZdA+4/l4RueevTWJd4yK2ZgdASTQGCCVi9lYI8zYWEK7ytWCgj9xsCNW4bo7ubz1x5LzrNQ= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(136003)(39850400004)(396003)(376002)(346002)(46966006)(36840700001)(110136005)(356005)(82740400003)(966005)(6506007)(70206006)(5660300002)(82310400003)(81166007)(70586007)(47076005)(33656002)(86362001)(7696005)(316002)(2906002)(54906003)(83380400001)(9686003)(55016002)(450100002)(26005)(36860700001)(4326008)(8676002)(336012)(8936002)(52536014)(186003)(478600001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2021 01:00:36.4089 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 873a4a43-56ff-47f4-9280-08d8f184e5cb X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT037.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3575 Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH] rte_ring: fix racy dequeue/enqueue in ppc64 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] rte_ring: fix racy > dequeue/enqueue in ppc64 >=20 > No reply after more than 2 years. > Unfortunately it is probably outdated now. > Classified as "Changes Requested". Looking at the code, I think this patch in fact fixes a bug. Appreciate reb= asing this patch. The problem is already fixed in '__rte_ring_move_cons_head' but needs to be= fixed in '__rte_ring_move_prod_head'. This problem is fixed for C11 version due to acquire load of cons.tail and = prod.tail. >=20 >=20 > 17/07/2018 05:34, Jerin Jacob: > > From: Takeshi Yoshimura > > > > Cc: olivier.matz@6wind.com > > Cc: chaozhu@linux.vnet.ibm.com > > Cc: konstantin.ananyev@intel.com > > > > > > > > > Adding rte_smp_rmb() cause performance regression on non x86 > platforms. > > > > Having said that, load-load barrier can be expressed very well > > > > with C11 memory model. I guess ppc64 supports C11 memory model. If > > > > so, Could you try CONFIG_RTE_RING_USE_C11_MEM_MODEL=3Dy for ppc64 > > > > and check original issue? > > > > > > Yes, the performance regression happens on non-x86 with single > > > producer/consumer. > > > The average latency of an enqueue was increased from 21 nsec to 24 > > > nsec in my simple experiment. But, I think it is worth it. > > > > That varies to machine to machine. What is the burst size etc. > > > > > > > > > > > I also tested C11 rte_ring, however, it caused the same race conditio= n in > ppc64. > > > I tried to fix the C11 problem as well, but I also found the C11 > > > rte_ring had other potential incorrect choices of memory orders, > > > which caused another race condition in ppc64. > > > > Does it happens on all ppc64 machines? Or on a specific machine? > > Is following tests are passing on your system without the patch? > > test/test/test_ring_perf.c > > test/test/test_ring.c > > > > > > > > For example, > > > __ATOMIC_ACQUIRE is passed to __atomic_compare_exchange_n(), but I > > > am not sure why the load-acquire is used for the compare exchange. > > > > It correct as per C11 acquire and release semantics. > > > > > Also in update_tail, the pause can be called before the data copy > > > because of ht->tail load without atomic_load_n. > > > > > > The memory order is simply difficult, so it might take a bit longer > > > time to check if the code is correct. I think I can fix the C11 > > > rte_ring as another patch. > > > > > > >> > > > >> SPDK blobfs encountered a crash around rte_ring dequeues in ppc64. > > > >> It uses a single consumer and multiple producers for a rte_ring. > > > >> The problem was a load-load reorder in rte_ring_sc_dequeue_bulk(). > > > > > > > > Adding rte_smp_rmb() cause performance regression on non x86 > platforms. > > > > Having said that, load-load barrier can be expressed very well > > > > with C11 memory model. I guess ppc64 supports C11 memory model. If > > > > so, Could you try CONFIG_RTE_RING_USE_C11_MEM_MODEL=3Dy for ppc64 > > > > and check original issue? > > > > > > > >> > > > >> The reordered loads happened on r->prod.tail in > > > > There is rte_smp_rmb() just before reading r->prod.tail in > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > _rte_ring_move_cons_head(). Would that not suffice the requirement? > > > > Can you check adding compiler barrier and see is compiler is > > reordering the stuff? > > > > DPDK's ring implementation is based freebsd's ring implementation, I > > don't see need for such barrier > > > > https://github.com/freebsd/freebsd/blob/master/sys/sys/buf_ring.h > > > > If it is something specific to ppc64 or a specific ppc64 machine, we > > could add a compile option as it is arch specific to avoid performance > > impact on other architectures. > > > > > >> __rte_ring_move_cons_head() (rte_ring_generic.h) and ring[idx] in > > > >> DEQUEUE_PTRS() (rte_ring.h). They have a load-load control > > > >> dependency, but the code does not satisfy it. Note that they are > > > >> not reordered if __rte_ring_move_cons_head() with is_sc !=3D 1 > > > >> because cmpset invokes a read barrier. > > > >> > > > >> The paired stores on these loads are in ENQUEUE_PTRS() and > > > >> update_tail(). Simplified code around the reorder is the following= . > > > >> > > > >> Consumer Producer > > > >> load idx[ring] > > > >> store idx[ring] > > > >> store r->prod.tail load r->prod.tail > > > >> > > > >> In this case, the consumer loads old idx[ring] and confirms the > > > >> load is valid with the new r->prod.tail. > > > >> > > > >> I added a read barrier in the case where __IS_SC is passed to > > > >> __rte_ring_move_cons_head(). I also fixed > > > >> __rte_ring_move_prod_head() to avoid similar problems with a singl= e > producer. > > > >> > > > >> Cc: stable@dpdk.org > > > >> > > > >> Signed-off-by: Takeshi Yoshimura > > > >> --- > > > >> lib/librte_ring/rte_ring_generic.h | 10 ++++++---- > > > >> 1 file changed, 6 insertions(+), 4 deletions(-) > > > >> > > > >> diff --git a/lib/librte_ring/rte_ring_generic.h > > > >> b/lib/librte_ring/rte_ring_generic.h > > > >> index ea7dbe5b9..477326180 100644 > > > >> --- a/lib/librte_ring/rte_ring_generic.h > > > >> +++ b/lib/librte_ring/rte_ring_generic.h > > > >> @@ -90,9 +90,10 @@ __rte_ring_move_prod_head(struct rte_ring *r, > unsigned int is_sp, > > > >> return 0; > > > >> > > > >> *new_head =3D *old_head + n; > > > >> - if (is_sp) > > > >> + if (is_sp) { > > > >> + rte_smp_rmb(); > > > >> r->prod.head =3D *new_head, success =3D 1; > > > >> - else > > > >> + } else > > > >> success =3D rte_atomic32_cmpset(&r->prod.h= ead, > > > >> *old_head, *new_head); > > > >> } while (unlikely(success =3D=3D 0)); @@ -158,9 +159,10 @@ > > > >> __rte_ring_move_cons_head(struct rte_ring *r, unsigned int is_sc, > > > >> return 0; > > > >> > > > >> *new_head =3D *old_head + n; > > > >> - if (is_sc) > > > >> + if (is_sc) { > > > >> + rte_smp_rmb(); > > > >> r->cons.head =3D *new_head, success =3D 1; > > > >> - else > > > >> + } else > > > >> success =3D rte_atomic32_cmpset(&r->cons.h= ead, *old_head, > > > >> *new_head); > > > >> } while (unlikely(success =3D=3D 0)); > > > >> -- > > > >> 2.17.1 >=20 >=20