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 EB44E45B13; Fri, 11 Oct 2024 17:49:13 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 834594028B; Fri, 11 Oct 2024 17:49:13 +0200 (CEST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2068.outbound.protection.outlook.com [40.107.22.68]) by mails.dpdk.org (Postfix) with ESMTP id A99504025F for ; Fri, 11 Oct 2024 17:49:12 +0200 (CEST) ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=C7JKR05552zUe/9tJ02ZwVcAl8WaYnyfuG8j01MlTQPiLgcvJVRiARfR7AQRJPCCDtG5i8QO4HeKY2SHKEOx5VINjky1yDX5sC/zfp71VWgKzwI8dj5hDn0e9aM4hGzNhhTNaWhLUKo5HWWuK5wUlAyujylEnAFrPW5p+0cEFKY8zrBEX/SvegK2z/IGx7l53ad/I0aPqw09y5tExJO5FzndEQcSqy5Jlnzk4BXBcI1W33xJTpsf59EdjtEIm6d41r5Pp7ZTBQ6VbJGYwpHJKnCJLyO9fL4s6vV+/615ZpPQfSfM6xj/knN7Y4dAUyEtiesQB8v1xUpKKrFjCGKOQw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oV7Wiz4qNDEeMdbPWLN/k6l4s+TvjWM1mzPnh+ruZKI=; b=f63nib156y2sVJOqkeHBUtBEl2MaMgZaL6Vn/508l/J+aP9ue4UEOXvorxhUsqCdp35HdNZplQsgfyirw9bUJNK9UGwaSPwcQ/wc04uY+gHpotHWoDKaE6BNfoX5DmsyPyC1NvrDbT+lfvDmexq/CpNOrYIIL8ZGJsmg75u82B8SgNG12LQdg5ROh1LaTHDeaNziZ6/ljfS8DzB6xHEQ7b35d6oBVQ/o50Sa90E+/niGpPfnjxP16syhDSqUkNKFJ4/Jk//qhuBRuVLvaEgqbAyQEoK53oP1FlEiQM8Yae9NTDa8K5hEdzS7XW01Fo5MxjO9+AaB503SfpCYEog1pg== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=dpdk.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oV7Wiz4qNDEeMdbPWLN/k6l4s+TvjWM1mzPnh+ruZKI=; b=JLgKhS0b7o7wIX/1HNCAqk25cb1qGDN06TKxcsP6rs6310zBfSAnPrYAKnbfg+kQSPjbgyevxkLg0U3LL+GbOoiKVGFCn4RAvS1XKcaVsgas0FHQgD1edJ9aTUw+wZgjvPL+84g7knbcBKRevaOe/rx/g4clxy02TPqHjIuuK6k= Received: from AS8P189CA0010.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:31f::9) by DB9PR08MB6441.eurprd08.prod.outlook.com (2603:10a6:10:252::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8048.18; Fri, 11 Oct 2024 15:49:07 +0000 Received: from AMS0EPF000001A3.eurprd05.prod.outlook.com (2603:10a6:20b:31f:cafe::81) by AS8P189CA0010.outlook.office365.com (2603:10a6:20b:31f::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8048.19 via Frontend Transport; Fri, 11 Oct 2024 15:49:07 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;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; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AMS0EPF000001A3.mail.protection.outlook.com (10.167.16.228) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.7918.13 via Frontend Transport; Fri, 11 Oct 2024 15:49:07 +0000 Received: ("Tessian outbound cd6aa7fa963a:v473"); Fri, 11 Oct 2024 15:49:06 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 5172a23b2408a133 X-TessianGatewayMetadata: Y/zINvk4TVy6Q06l8ezyeDbohvj+8fDwfaMXpub/DXXnzGRbycNcwx581VjnrVjGHBmqpzXFvY45qlF3aKH4bAEZbkUt/T61b/bbbUAoqYjcLpV5a63d7b7AnItS+/Dn2CBvbHZIr5jvmBebAxtXqK13mPZp+6h6v412+r5a0YAwYCjFO/v3OQq51VLuclMQjncLUL0Rv5J0JbHdISFktg== X-CR-MTA-TID: 64aa7808 Received: from La3f37dc39e8a.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 1CC80232-3E5E-4B88-8476-8325871F2206.1; Fri, 11 Oct 2024 15:48:56 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id La3f37dc39e8a.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 11 Oct 2024 15:48:56 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mSp9w5xN++dog19A2xpnT9EW/d7z/BKOsRyISDBei0t+nmSw4Aw5lNkVwZOnCDkMwAktlWVwp7BF/1aMv+SVKV8Zqihqo9sLMz5p7i8hMhfDWrk1KIGDeY2oP/UT6NGCKVz6X7wpL2aPdFwuO/pC5XOs3Fta79DpwJKNEoca4fM4QY4601plqTVdp+J2QDjHugTpwNwsjOJIDxzGcoofddswqEhMbNQ8ULL5AmDmtvq1gRmF6EeDWEAGn7WzleacBnuWcwVUFMebr8crrJeBaJP3X+xskyLicJAXyQdCb7t+ZYaMFEh93ByvOeySCzy4XMm6lmUDTDDiKLT4Eu9e1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oV7Wiz4qNDEeMdbPWLN/k6l4s+TvjWM1mzPnh+ruZKI=; b=rFG5RTXjIHmNLAiCGPKzsgUOXo0n2U75NMsqe7Bpj8GLCq3GHkyczOAsrTYRy5byFpPhDYJE0TKtrDo0jfXqn2ntaFyNgXp9TkDNF4t4nnwMl1cX9k55ctEgfhB47lBn7SHna1gITLQyLCAvxpCAXKfEXEPZUn6GZtchPXb7h56OC7wshSDdJ05HLKnsKybd37pGkYVQ2QUXSfDgZ3kbk2UgHSeflm+asY9CAE4Z8QOMw7vXWAe9JYlBGXhQF6QlEQwhVR+yCPecEs50YCfqqyFFmwVaVK5o6DyWw26BhamuuL4BBjoStHE1lMbn+dDvS02CJZo5/K/XrTG48nd0Sg== 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=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oV7Wiz4qNDEeMdbPWLN/k6l4s+TvjWM1mzPnh+ruZKI=; b=JLgKhS0b7o7wIX/1HNCAqk25cb1qGDN06TKxcsP6rs6310zBfSAnPrYAKnbfg+kQSPjbgyevxkLg0U3LL+GbOoiKVGFCn4RAvS1XKcaVsgas0FHQgD1edJ9aTUw+wZgjvPL+84g7knbcBKRevaOe/rx/g4clxy02TPqHjIuuK6k= Received: from PAWPR08MB8909.eurprd08.prod.outlook.com (2603:10a6:102:33a::19) by GV2PR08MB10383.eurprd08.prod.outlook.com (2603:10a6:150:b0::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8048.16; Fri, 11 Oct 2024 15:48:52 +0000 Received: from PAWPR08MB8909.eurprd08.prod.outlook.com ([fe80::613d:8d51:60e5:d294]) by PAWPR08MB8909.eurprd08.prod.outlook.com ([fe80::613d:8d51:60e5:d294%6]) with mapi id 15.20.8048.017; Fri, 11 Oct 2024 15:48:52 +0000 From: Wathsala Wathawana Vithanage To: Konstantin Ananyev , "dev@dpdk.org" CC: Honnappa Nagarahalli , "jerinj@marvell.com" , "drc@linux.ibm.com" , nd Subject: RE: rte_ring move head question for machines with relaxed MO (arm/ppc) Thread-Topic: rte_ring move head question for machines with relaxed MO (arm/ppc) Thread-Index: AdsZem51pV3bFdnOQj2Lv/oX5wHuJQAE4tywAAJgEaAAAKmmgAA1OCnAAC+O+rAADhtAsAAe4csQAAI+2vA= Date: Fri, 11 Oct 2024 15:48:52 +0000 Message-ID: References: <8139916ad4814629b8804525bd785d58@huawei.com> <0badc1b8ea524bf3b69d0b7b316bdc8f@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PAWPR08MB8909:EE_|GV2PR08MB10383:EE_|AMS0EPF000001A3:EE_|DB9PR08MB6441:EE_ X-MS-Office365-Filtering-Correlation-Id: 8c95a6ea-b9dc-4a3e-adf1-08dcea0c3d70 x-ld-processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; ARA:13230040|376014|1800799024|366016|38070700018; X-Microsoft-Antispam-Message-Info-Original: =?us-ascii?Q?Zk3kJW5d7QfSE5vnIchGyXgzSAeQi6/GiW5MA9OgA5Mr2KbUnMLbfoN6r4v7?= =?us-ascii?Q?a9WPD5Inu30zZc8ZrMncq95f23y1I76pn/HRrAmuWvuVlJcpvRocMKDKLwDq?= =?us-ascii?Q?Fdy22fT5kVsZU1v3rrVp6MJSUTkISfU/2/ormN5zllX8KC9tUOnWrtXK6KIX?= =?us-ascii?Q?XfYhMlQulF4FrnaJy9hBtsiRCZrTtTSLcfJroKjVLeqFWdmv6Sy6VSLQbqX+?= =?us-ascii?Q?W83G0KS8k4YmH3aX1QNMSa+DdB7yeJ8tXL4hMl7XHNn3pcYYPIubsDS089Ei?= =?us-ascii?Q?svtcWpIx28bgei8JZkNJCf8ha62CE0Qn1MhveM9EJRAOGU6+cgkUePu/F9uz?= =?us-ascii?Q?CxosiDvMnxIJxqkgV+oXVPGDqMAAGS6DE9Sn4lStRUbTl6gtzIJpg37LocDd?= =?us-ascii?Q?B5hDX7WBFK1EJv2H2Oxrp6p43A7MrpwQibtJ82LjwjLOzOMjv4EIw1MN+0Nd?= =?us-ascii?Q?pLDDGz62zGHoORIRaLIJ/Et4JdI8MLwaCnF8JKCnrEnVXfYedDIMARdzmSkS?= =?us-ascii?Q?DnuhoUH4+UGaSJOR6HGVsG+EPpZuvs0zpH/x/zNA0Eumdte4Z1JxhHa+mrJK?= =?us-ascii?Q?9Ixh2E1kRGTlzUCA2rXBO/qo0XvIU+iB+v5SaasGTls28QT7ERg4D7pXxGgL?= =?us-ascii?Q?wic4NEDfrQsVWXdWKN/HRpTJq6b1s6Q9SaA+LSkxor3NcEJqaRaocHp++OwV?= =?us-ascii?Q?nHH2D9Zw6cGyLfHTr+/DXNYDcS5UrtGDDuf+iUkf+hk1XtviMyw54xh6OhRp?= =?us-ascii?Q?m/E3Lpsw34I0Sv8HjTuRh9y+um+OkQ9PCnmpw63m/lhnWtAJvcfalJTKQ8fH?= =?us-ascii?Q?/euJ+TcDVgKo5eICEEO2uv0Kt/+RKEBABu4wf2Me4UNPo68b2QNAMNU3JfiS?= =?us-ascii?Q?X/Cv9QV0+mQ7QF6pFU5mJh4mNrWOMdAXi3Xqb08MKlgLl4orDxQsktTwOS03?= =?us-ascii?Q?BjZP33aYL4efydx4mkcnATScbqBUR/MwxrCMIbkzC0VW9fVXQU27I3aGKMej?= =?us-ascii?Q?d66tADIZNSn286of5PfyWQjQVX7beQmcqT6MLRWfzZvaf9JWBWZbhlwFqB0U?= =?us-ascii?Q?xrvZa0OF2f+m+x4EHrZrDYlIScy034mW2nMlRJ1zi5lhZ5BGaiY/Q4sY/Mrt?= =?us-ascii?Q?br7dbmlbNAeAlwTRAzJd3lx04EXZEMJG7feXAwgTNkKvVLn0tpYHaySUteDd?= =?us-ascii?Q?BR5f0bmX2p0uSQJc7uk+lsngEWBYV921EHtkP7G/q9nnumTLUtUz96ZuH7CZ?= =?us-ascii?Q?4XXN1zrXIx304lr0FOFTdT8sfJ6+Du6VAlqw68xXKg=3D=3D?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PAWPR08MB8909.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(376014)(1800799024)(366016)(38070700018); DIR:OUT; SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR08MB10383 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-SkipListedInternetSender: ip=[2603:10a6:102:33a::19]; domain=PAWPR08MB8909.eurprd08.prod.outlook.com X-MS-Exchange-Transport-CrossTenantHeadersStripped: AMS0EPF000001A3.eurprd05.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: dcea5497-01f5-4e48-eefa-08dcea0c347e X-Microsoft-Antispam: BCL:0; ARA:13230040|36860700013|30052699003|35042699022|1800799024|82310400026|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?En+JAoa866HfDEUZDyMDlEaj8xDabqDAa67wDvCpnJE7ymYDvDO9054zHaNr?= =?us-ascii?Q?Y7dTFJu71m/CWxDdQZINgtyiHJhOknrK4d9fDOhzl167UqtwI7P6VF9X8W/n?= =?us-ascii?Q?LEySW2y2nc9Xf5PkK2b9eig4Yi9hbK1ZBFKr4tSfZpSTWErUZTd7JTrx+A5c?= =?us-ascii?Q?xPD0/PMXNNotX+4bp6OBec9u1jjNVeVaylGeB9HTGFRht/Dip64xHPBxxuNi?= =?us-ascii?Q?lvzDU6/w4Y8hypfeBJu64LWmq1V3achZ6IBOem7Y2nmUYnB/hbux58ja+c5k?= =?us-ascii?Q?h0mID9QvO3eoTVggjTxedLlUF6qjTNzFqhKBhVqWmNS5OLp1QdL81ojoIZ3I?= =?us-ascii?Q?/jBI62UBQwWdYTE7HtP16DOYtAlqJcTAddQmoI34Uxmtg08ilQ5TyxpUDqRS?= =?us-ascii?Q?L1OhyZezrCT/iYRACjxUS31jo/kfRl8DWIE/DehoICuELvVsTHYZEdJcvsyE?= =?us-ascii?Q?MrF3IXi0r8UXHZcqehlhRTMmI6ahSuo1x9KZZjWpQ3h/uDcfl8KCBbJlFmEV?= =?us-ascii?Q?yuFiwhfC8m68ZR9hFhQJ+mdW+zcZEICli1xBoN7ku1OrcLUHKPxNAIwbNSoE?= =?us-ascii?Q?cGlPHdGeJSArxqPubFEC3F3Ca47rOq6qpYH5MOm0Bh+gRYw+UfU4m+kW4/Gw?= =?us-ascii?Q?CJTHwftLBSl1ImycE9uv2ScJqI8tl7nczx87MQsdSIKDUvTdv+oMiShRAqET?= =?us-ascii?Q?YW76KxJtjtJhEwgZ7pWAUKIfMmFJymWdBJW1StcK8wZMYlMSWggZN60ABBDC?= =?us-ascii?Q?SHYV31t23f0AHpJfPA6qmbWz8nN0w9ZX3ILtfLIxpYLkPSYnV+0tCuZrY3Ij?= =?us-ascii?Q?3q+6l4IrPhfp11GMbIU3rVK48/JnZY1rUog9SkNeLkfVMUwCZqDqczcyZr1/?= =?us-ascii?Q?epCgJlps2obFPS5WKhI8PhtA7kHppYhinO9/cruWAJPDlXWzUCMdPXmzJ5hT?= =?us-ascii?Q?w2NgQzQLOYDFeiuR2p1Dmx3bKsjuD0dZPrA8BC1X8ndco61Up3XUd5dpJkC+?= =?us-ascii?Q?4IiKqBzVzmvbCfIHIOy0VjrWaWu7CuRPVYOwzTU/3fBWsE7JioVHTc4qodx1?= =?us-ascii?Q?rsQHZOPHJXAVzJzljfDhMleYDYV+LSBLtC/eX41Coqhkg0ka5OTqqjBXjZRm?= =?us-ascii?Q?LCIgFXuTnhOO2qCpmWH9Lry+jF+8lffFm8CpPN1AUO+CS2xSB+jpCpZz5f8o?= =?us-ascii?Q?gcVoQdD6xLidh6N1m885TtbFunUZBU45ZTlVOcsVz9AE0/8L6VplCriwjj5z?= =?us-ascii?Q?xsBqFwpY5KlOiNuwL9/MJXxqhiN9ZACxgr48/pv/wuHnHOmxZz6Jrg30cmo9?= =?us-ascii?Q?XSOpOIjbEke563ZAH7KS/ho3?= 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:(13230040)(36860700013)(30052699003)(35042699022)(1800799024)(82310400026)(376014); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Oct 2024 15:49:07.0444 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8c95a6ea-b9dc-4a3e-adf1-08dcea0c3d70 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: AMS0EPF000001A3.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB6441 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 > -----Original Message----- > From: Konstantin Ananyev > Sent: Friday, October 11, 2024 9:09 AM > To: Wathsala Wathawana Vithanage ; > dev@dpdk.org > Cc: Honnappa Nagarahalli ; > jerinj@marvell.com; drc@linux.ibm.com > Subject: RE: rte_ring move head question for machines with relaxed MO > (arm/ppc) >=20 >=20 >=20 > > > > > > > > > > > 1. rte_ring_generic_pvt.h: > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > > > > > > > > > > > > > > > pseudo-c-code // = related armv8 instructions > > > > > > > > -------------------- = ------------------------------ > ---- > > > ---- > > > > > > > > head.load() // = ldr [head] > > > > > > > > rte_smp_rmb() // = dmb ishld > > > > > > > > opposite_tail.load() // = ldr [opposite_tail] > > > > > > > > ... > > > > > > > > rte_atomic32_cmpset(head, ...) // ldrex[head];= ... > stlex[head] > > > > > > > > > > > > > > > > > > > > > > > > 2. rte_ring_c11_pvt.h > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > > > > > > > > > > > > > > > pseudo-c-code // = related armv8 > instructions > > > > > > > > -------------------- = ------------------------------ > ---- > > > ---- > > > > > > > > head.atomic_load(relaxed) // ldr[hea= d] > > > > > > > > atomic_thread_fence(acquire) // dmb ish > > > > > > > > opposite_tail.atomic_load(acquire) // lda[opposite= _tail] > > > > > > > > ... > > > > > > > > head.atomic_cas(..., relaxed) // ldrex[= haed]; ... > strex[head] > > > > > > > > > > > > > > > > > > > > > > > > 3. rte_ring_hts_elem_pvt.h > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > > > > > > pseudo-c-code // = related armv8 > instructions > > > > > > > > -------------------- = ------------------------------ > ---- > > > ---- > > > > > > > > head.atomic_load(acquire) // lda [hea= d] > > > > > > > > opposite_tail.load() // = ldr [opposite_tail] > > > > > > > > ... > > > > > > > > head.atomic_cas(..., acquire) // ldaex[h= ead]; ... > strex[head] > > > > > > > > > > > > > > > > The questions that arose from these observations: > > > > > > > > a) are all 3 approaches equivalent in terms of functionalit= y? > > > > > > > Different, lda (Load with acquire semantics) and ldr (load) a= re > different. > > > > > > > > > > > > I understand that, my question was: > > > > > > lda {head]; ldr[tail] > > > > > > vs > > > > > > ldr [head]; dmb ishld; ldr [tail]; > > > > > > > > > > > > Is there any difference in terms of functionality (memory ops > > > > > ordering/observability)? > > > > > > > > > > To be more precise: > > > > > > > > > > lda {head]; ldr[tail] > > > > > vs > > > > > ldr [head]; dmb ishld; ldr [tail]; vs ldr [head]; dmb ishld; lda > > > > > [tail]; > > > > > > > > > > what would be the difference between these 3 cases? > > > > > > > > Case A: lda {head]; ldr[tail] > > > > load of the head will be observed by the memory subsystem before > > > > the load of the tail. > > > > > > > > Case B: ldr [head]; dmb ishld; ldr [tail]; load of the head will > > > > be observed by the memory subsystem Before the load of the tail. > > > > > > > > > > > > Essentially both cases A and B are the same. > > > > They preserve following program orders. > > > > LOAD-LOAD > > > > LOAD-STORE > > > > > > Ok, that is crystal clear, thanks for explanation. > > > > > > > > > > Case C: ldr [head]; dmb ishld; lda [tail]; load of the head will > > > > be observed by the memory subsystem before the load of the tail. > > > > > > Ok. > > > > > > > In addition, any load or store program order after lda[tail] will > > > > not be observed by the memory subsystem before the load of the tail= . > > > > > > Ok... the question is why we need that extra hoisting barrier here? > > > From what unwanted re-orderings we are protecting here? > > > Does it mean that without it, ldrex/strex (CAS) can be reordered > > > with load[cons.tail]? > > > > > > Actually, we probably need to look at whole picture: > > > > > > in rte_ring_generic_pvt.h > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > ldr [prod.head] > > > dmb ishld > > > ldr [cons.tail] > > > ... > > > /* cas */ > > > ldrex [prod.head] > > > stlex [prod.head] /* sink barrier */ > > > > > > in rte_ring_c11_pvt.h > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > ldr [prod.head] > > > dmb ishld > > > lda [cons.tail] /* exrea hoist */ > > > ... > > > /* cas */ > > > ldrex [prod.head] > > > strex [prod.head] > > > > Minor thing, ldrex and strex is how Arm 32 way of doing CAS. > > Aaarch64 has a cas instruction. > > Same code in aarch64 armv9-a https://godbolt.org/z/TMvWx6v4n >=20 > Cool, thanks. >=20 > > > > > > > > So, in _genereic_ we don't have that extra hoist barrier after > > > load[con.tail], but we have extra sink barrier at cas(prod.tail). > > > > > > > You are right, technically, that lda[cons.tail] is not required > > because due to the dependency chain up until CAS a memory reordering is > not possible. > > For that reason, it has no issue synchronizing with the strl[prod.tail]= (in tail- > update). > > C11 standard calls it consume-memory-order (__ATOMIC_CONSUME in > GCC). > > > > So, ideally one could have written something like... > > __atomic_load_n(prod.head, __ATOMIC_CONSUME); instead of > > __atomic_load_n(prod.head, __ATOMIC_ACQUIRE); > > > > The compiler is then supposed to figure out if there are any > > dependencies in the code path to ensure that load of the prod.head is > > observed before any load/store that's program order after the load of t= he > prod.head. > > If not, the compiler is supposed to add required barrier to ensure > > that order is preserved. > > > > However, it's easier said than done. No, compiler implements it and > > C11 standard discourages use of memory-order-consume for that reason. > > > > This brings us to the next caveat. As per C11 standard, there cannot > > be a free standing Store with release semantics (stlr) that isn't > > paired with a load with acquire or consume semantics. Since we can't > > use __ATOMIC_CONSUME (which would have resulted in ldr[prod.head]), > we are forced to use __ATOMIC_ACQUIRE (which results in lda[prod.head]). > > > > > > > If that's correct observation, can we change _c11_ implementation to > > > match _generic_ one by: > > > > > > atomic_load(prod.head, releaxed); > > > atomic_thread_fence(acquire); > > > atomic_load(cons.tail, releaxed); > > > .... > > > atomic_cas(prod.head, release, relaxed); ? > > > > > > From my understanding that should help to make these 2 implantations > > > Identical, and then hopefully we can get rid of rte_ring_generic_pvt.= h. > > > > > > > They both are functionally correct. > > _generic is correct but does not comply with the C11 specification. > > _c11 is correct and fully compliant with the C11 specification. >=20 > So far, I didn't say they are 'functionally incorrect'. > The problem is - we have two implementations for exactly the same thing t= hat > generate different code-sequence for the same platform. > By default It is switched on/off depending on the platform ('off' - at > arm/thunderx, ppc, x86, 'on' on other arms and riscv ). > So for some platforms _c11_ is probably never used (and less tested), whi= le on C11 is guaranteed to work on all platforms if built with a C11 compliant co= mpiler. > others _generic_ is not used and under tested. _generic_ by chance sets a dependency chain up to the point array operation= s are done, so there is an implicit head.load(consume). It's possible that there = can be a platform/compiler combination that does not do that. > Obviously it is not a good situation and better be addressed. > As I remember the reason while we ended up with 2 code-paths here - on > some platforms _c11_ one was slower. > Honnappa, please correct me if I am wrong here. > So ideal solution seems be - make _c11_ generate exactly the same > code as current _generic_, so we can deprecate and remove _generic_. >=20 Ideal solution would be to make _generic_ generate the same code _c11_ generates for the above reasons. But, at least for Arm, when compiled with GCC we know that there is a dependency chain that guarantees the program=20 order (implicit consume), so it's safe to use and slightly more performant.= =20 > > Replacing atomic_load(cons.tail, acquire) with load(cons.tail, > > relaxed) in > > _c11 would make it non-compliant with C11 the spec. >=20 > Hmm... where this constraint comes from exactly? > AFAIK, inside DPDK, we have several places where we do use > 'atomic_store(var, release);' in conjunction with 'var.atomic_load(relaxe= d);' That's ok, such code can exist just like in _generic ring. As long as they are correct on all supported platforms and no one states it= 's C11 compliant, there is no issue, no? >=20 > Again, if that really that strict - why in _c11_ move_head() it is ok to= use > 'head.load(acquire)' in conjunction with 'head.cas(relaxed);'? > Following that logic, it should always be 'head.cas(release);', no? >=20 _c11_move_head() does not head.load(acquire), it's head.load(relaxed). there is a tail.load(acquire) which must synchronize with tail.store(releas= e). Prod Cons ------ ------- ProdHead.load(relaxed) ConsHead.load(relaxed) ConsTail.load(acquire) ProdTail.load(acquire) ProdHead.cas(relaxed) ConsHead.cas(relaxed) AddToArray RemoveFromArray ProdTail.store(release) ConsTail.store(release) Above is how _c11 is implemented.=20 ConsTail.load(acquire) in Prod synchronizes with the ConsTail.store(releas= e) In Cons. ProdTail.load(acquire) in Cons synchronizes with the ProdTail.store(release= ) In Prod. If you want, you can switch to ConsTail.load(consume) and ProdTail.load(con= sume). But, due to lack of support as explained before that results identical to=20 ConsTail.load(acquire) and ProdTail.load(acquire).=20 Also, C11 standard highly discourage it's use for the time being.