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 5E24945B0B; Fri, 11 Oct 2024 02:11:32 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2AF0C402E1; Fri, 11 Oct 2024 02:11:32 +0200 (CEST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2057.outbound.protection.outlook.com [40.107.20.57]) by mails.dpdk.org (Postfix) with ESMTP id 848E1402D3 for ; Fri, 11 Oct 2024 02:11:30 +0200 (CEST) ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=AC1cA/38o5XKoUA19hPU9V05MAIC4H0jhGxdRcsRgx1teJFJ3Ap/KXxjK9NDINSPGtuur0YhdpVyHw/IIwzm1Xf3YXTgKVb6aTb1WhAMgcmvqfY08pYWt91tL/cL7VZQ0/Ek5GB29XuVHIwiqnt7e89Quf8kTpmdMpH21UD4wZY+8FWvw8HBudq2Twl7ZLm7K78T9J3nbAlFMxEL2k7gmc09tRein5qc78XX2u7Htx6C2wjsBxJSO6X9c+gDwnnwV0DuU19+Hhw0dwfCJEVUCZwCGsF4P0RDvNlalIvm1pZGiM0E+rx+N6FMjPzIG06hRTtSS+96EoFlcuJYEUmT5A== 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=yy/FRjwGRuvK1eLDgWXYKHOfz6SKknv8+rqLXlmMNFc=; b=vyXSB2muW9Igv/652rfqFyTMvJ7umj7taWPcp4AV5XkJzquLcRiaoDkkC2SWyvPuWdl3bykBOfm3WqAWBhutnoO/vKgTMlf0ZDBz3emSxliRjby7vrgvEk4q+LOy/xszRu6Uowao/+wFs1aF80+RSLjz+DvKENRm5vrSa1o/v/xnvHDEg8GP9SfhYc9WrbbaYmrkEuVcNKe2vWQDqiKc9RdUyiQpEfjc5oZ1jFfqwrK6oeHxKUBgMUfZ2frbzu9dOjnVQatCTp9ydsgSCME7+K4jdfu3Di6Eeud3WinFyicCNSPjmaWjPIaNW6tlbnEh+YSqFaAPDZusT8wOhLoryg== 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=yy/FRjwGRuvK1eLDgWXYKHOfz6SKknv8+rqLXlmMNFc=; b=CuuQnD54jVVRODeQf8Gk7ETsKf41z9L0NAmB+uGWzuAgzMYAN7mCTdACXuj+WO4CpshbqvtsWRVMN2NQzVEh4mllOLYAYirDpmz6RteY0HOkFezUdVFHqLwRfGqbx2eJZirPPEH2ocvnoEYYKfpwHW/fO8KWZev+BY8eyydydJU= Received: from AS9PR04CA0113.eurprd04.prod.outlook.com (2603:10a6:20b:531::18) by DU0PR08MB9935.eurprd08.prod.outlook.com (2603:10a6:10:401::19) 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 00:11:25 +0000 Received: from AMS0EPF0000019E.eurprd05.prod.outlook.com (2603:10a6:20b:531:cafe::7e) by AS9PR04CA0113.outlook.office365.com (2603:10a6:20b:531::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8048.20 via Frontend Transport; Fri, 11 Oct 2024 00:11:25 +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 AMS0EPF0000019E.mail.protection.outlook.com (10.167.16.250) 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 00:11:24 +0000 Received: ("Tessian outbound 5e8afd4f8faf:v473"); Fri, 11 Oct 2024 00:11:24 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: e9155554b6bc8de9 X-TessianGatewayMetadata: dj2jrTO4Oy4tu/T5gH6wWC7PYrc2krOSqjJF3c9SDGLpC9ywSaOLxonvDlZWcXsI43/Axov1P1SV9EMKk9rtFI/qOrzXLM8MgOt0lrwoZmtWgnHFL7vRCSXdV8/Lfi8gbsbdeaxPY+CvBt+ZI2thONEDHFcRBjYbV8NeWQX/ypUZGqH9PKSUyZtZvYO4h5sOlWv9K6dTJqy0ZapLtww5Gw== X-CR-MTA-TID: 64aa7808 Received: from L95848651cde3.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id EFD407D9-C0BB-4247-BA9D-020DDE06571A.1; Fri, 11 Oct 2024 00:11:18 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id L95848651cde3.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 11 Oct 2024 00:11:18 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=j6DkRVk/NUY/+S02hndRjcmO7TCn5nODxF5MHf0N76WMcdw1HdJmsgIUQsVpmPL4lT+EPTTheXPxeOWCINSU8qy2w0ZdWPG6fo+oo/FlCQGlOXAz6uG2PCXIEe6RrwP7tR8fwAzObNwtq4MNkA7FX2dTiVRU/t4eOo9ZfSk6PZJntzyFuR1RwiTuhdFboMmSepyIs0lK1lMKIzu43UcEly6jaUp39iWJnJHi/uUcdc4BvZi0bx73dtD11mQ7PXFs95+YCWFSIq9RW03XCR7k3PVdq57UXxg4lJdJn0gkR3a4w6sFXN2RDZk79vbvBnhyrgguFpqXsUR3UlrUmxxqaw== 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=yy/FRjwGRuvK1eLDgWXYKHOfz6SKknv8+rqLXlmMNFc=; b=OCcasnAKLJZHbHRcSIeAe9pdKUECduAFsfvBmrP2cb1eOkSJMq5vkeBWwo0SAjzjsrVq93VGaTZqfmKFXyQF50KlGGwWGqIlYf9w98+AKb6i8gwFLaa3B6jRFBtF0DYIz4/Ax6RzNbsPpfv4OM+sGAoScpQ7+nRrxWL0a4Gbgjn1WvvJPEKYMP8u72O0Eprtp9C8JXGggl3DzbdWEPlHOmakatYA2JldxjbQDXZV+2gXBV2LtIkV0w/SaRAHStXcxFowvMNtezgXSqkLhBX/q2trSny6ZyuiQYeHiZmCN8RmOONhC7VdjCtXta3u0Al6bkaDG0mLwNr+46ASjMeFRA== 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=yy/FRjwGRuvK1eLDgWXYKHOfz6SKknv8+rqLXlmMNFc=; b=CuuQnD54jVVRODeQf8Gk7ETsKf41z9L0NAmB+uGWzuAgzMYAN7mCTdACXuj+WO4CpshbqvtsWRVMN2NQzVEh4mllOLYAYirDpmz6RteY0HOkFezUdVFHqLwRfGqbx2eJZirPPEH2ocvnoEYYKfpwHW/fO8KWZev+BY8eyydydJU= Received: from PAWPR08MB8909.eurprd08.prod.outlook.com (2603:10a6:102:33a::19) by AS8PR08MB9340.eurprd08.prod.outlook.com (2603:10a6:20b:5a8::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8026.23; Fri, 11 Oct 2024 00:11:16 +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 00:11:16 +0000 From: Wathsala Wathawana Vithanage To: Konstantin Ananyev , "dev@dpdk.org" CC: Honnappa Nagarahalli , "jerinj@marvell.com" , "drc@linux.ibm.com" , nd , 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+rAADhtAsA== Date: Fri, 11 Oct 2024 00:11:16 +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_|AS8PR08MB9340:EE_|AMS0EPF0000019E:EE_|DU0PR08MB9935:EE_ X-MS-Office365-Filtering-Correlation-Id: a315622c-9e15-42f8-43cb-08dce9893e92 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|1800799024|376014|366016|38070700018; X-Microsoft-Antispam-Message-Info-Original: =?us-ascii?Q?kZ4vlRPX3TBGc8y+u893UCgHkZZ7XdVnE7JSHEHPuWSJtQG0baDlEQLo6+pN?= =?us-ascii?Q?hPiSvSYNNP/5qWeOHgcaWo5+0u1c5bwiTdKRerIIVxPshk1FtEVIlU8Tb7RW?= =?us-ascii?Q?k/M5HXmJZCgHzRoelJOAMbBK7ZcK72SCq6bCK4dMTE9fgnpeMWwksD9SZ1zO?= =?us-ascii?Q?RxZbt/M3i+XsPBvVu3KZawMoN+f8pNiM/6mWqvRHojaPfMmj3InvB/6nxzqY?= =?us-ascii?Q?V0PoUvt8IyqPSrbFI3FEqRG4dt6LMsPZEQr9x3ZrAyK4oxXXirn+HuGTmhwC?= =?us-ascii?Q?jMxvJGbFgDu5hcrFCqx24YREtnXkBnmpTCfjkg44PfNs5rN8aatyYkyVWAG1?= =?us-ascii?Q?G7pzAw8N/7pPngNJk+O55V+X8/MAQAW7qBdccRTdZoo9OlD0eyZ0tJE1UX3p?= =?us-ascii?Q?p4sPysE1bpCK32Tp2/ECRAE1N/HJsM6qCPojo3FrD3hxg4kigxkWvGpsZU7t?= =?us-ascii?Q?OjgZ3pAj/U1vUhggLbd7DHuXkjAXAIqclwsws0unTsAQac7QewHFPa+3PMhL?= =?us-ascii?Q?lNmEnRLRL5knI1ro5Gs73HWqHTcV3+uIwP0qjxhHebzkmobJLsrJInI1WBwt?= =?us-ascii?Q?rPxIFh0UFVQVB4EOr6SqkFDRVqizE7bvDoiVHlkJPrbGYZzzP10YRBMCP1j4?= =?us-ascii?Q?SNoAjpNzNEjk3qaE2omAR/WCR6EV6jSDKeWGgbie2RipMl7LPuO7uvxurhor?= =?us-ascii?Q?GVWp5+dyrxyzGI+k1xlZfBGq7fmO5k9fu5zmfJpoVCRnQkZ072Oeh/T4+N6+?= =?us-ascii?Q?jVcuXxEUSMwGpQls3EiAAT+KHCT+53klpOutyehlMYQH31UTxbhma7dH4gZr?= =?us-ascii?Q?BN/0wCOlOGdFF/u07Q8WOrO9gnnoJHhwuGCeyFUiJ6NjPsVOLlyL6+GKXXv4?= =?us-ascii?Q?tiL2ig92duf0POvLQvgy7+kqfBO/nKurIuYvBlLM1+XR7llvyV+Ld6rc3gK3?= =?us-ascii?Q?4r0M6aQ5HqC1Zir119Y6tJM1KXxOwi7l1k+NE42Wcn4FYfRlyNqmnFyu3/rL?= =?us-ascii?Q?umAr8SvrBV00BVS6BnTzlhqZIgn9fWXBeosPPt2rAYX3JiDONWNzBxRqO2sj?= =?us-ascii?Q?gxL+LyauS+xWbErzp1Jf2eJvCMeGluoeuYYaXqGykdJBRhrLFr6BPrslPB/O?= =?us-ascii?Q?Zv9tKJBFYtQfcV8yk2NwuNbvYU4ufijB7syVRZ3tC+aETgmN7s1IiUq1SmKK?= =?us-ascii?Q?ea46hmwAocM0nZXBzsxn/7K8hNqDvEHMV918/o9gC9AcFtyQBS/pM4ZWVrVf?= =?us-ascii?Q?15JUgFGf/xO5JnU1DVQl2v3MGvsRNdvNYGR/UQguCg=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)(1800799024)(376014)(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: AS8PR08MB9340 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: AMS0EPF0000019E.eurprd05.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 6cccac4b-099f-4ee7-66d1-08dce989395d X-Microsoft-Antispam: BCL:0; ARA:13230040|36860700013|35042699022|1800799024|376014|82310400026; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?yKIlRbmJfMafo/L7lMPA3atBHvvVzTe1Inf4BqA1nhzLZaeZfLTG1T3aMvaP?= =?us-ascii?Q?3wkn2fyVt/fPGppPYHWVHl3aKe53IfZFS0LHxweyjMPM4W9FABHAK6T/83F9?= =?us-ascii?Q?92N3wVlyTssr0sdUJkH1wb8k7HWWLVOpU9xGxGry8TY/Pcwi4oCxi7+pCymA?= =?us-ascii?Q?hXLzzo7Vriy7e3Cpr5D/BGgq6oAbkWffNJGP3JeK/vsG2iSp7X8taW9tbvT2?= =?us-ascii?Q?cWdx+gR9Q6cDW7DU8i/i4Uy6IATt+9US8+3n0QOmcZWxSSma/Zu1WttL3Mis?= =?us-ascii?Q?MU2nFm9F/p/5Jg5TzJIKyXO27hB69w4y+uz2w74QaH1q/DLaBQVcZWY2a1rc?= =?us-ascii?Q?ORrW7uVniHx0k1Z6tJzWaLT/+rchL8eSETSgzUoTNm3tyLAUm9UoxlQCm4V2?= =?us-ascii?Q?MTuVDASXrei74Erl2BSf63nPlalI/KmjC1vycQg3DVhifXcHMti+H+ZVvb2Q?= =?us-ascii?Q?an6k9ZbmTp3XyjA1XIuJjyykqSCL5hOqEVQjqDVWxGl1bb5Fqe5U9FKf+Jc+?= =?us-ascii?Q?bftk/aj1aprkjkq2Yvf35fDXVwTVDnfxhk2CY9bq0tEn/QWiBVumsdLTEjlJ?= =?us-ascii?Q?S9lk8OeNAX0LUCLo+HbJ91RsrFjo5aHAbDZpugHQvB2mS68DExWr65MZdf4h?= =?us-ascii?Q?0mP9I1cES5idLxBGxNbnGDKXlB0RjVb62O4aDOCG99t4idWAofcd804jle8+?= =?us-ascii?Q?12S8+clHyofG0hNoN2c8Sy83lnsFaBfKXFvmiSGTwfndtXYyB6wTL4/CwLC7?= =?us-ascii?Q?PlzFhjZye9vHx0OzPud8YbUP1wOW6TuCOn+D9TReLngq9n1LBE0xl4F8Akco?= =?us-ascii?Q?FjnSfje0fUpeXzDcAJu9em8luoKjpHQn9sasumIInWVg7zITeW+Utul502i5?= =?us-ascii?Q?Qq5Y7W3j3a8ZRxQEjpieMkg8ZCQn2pNennmKCp9Hxa6yw1LQroqQ6PWpjtxF?= =?us-ascii?Q?Hn1zCvlCs5LOH2gEZ/WUng7LnCp8dBp/0nWao4Nb2wi4dSrzTsn01NrGRMGS?= =?us-ascii?Q?veMGA4oC8z8OfiBGr7k9NxWKGQiHWXMxVr6VwLbHKbzHKEDh4hNJxmtt8QNE?= =?us-ascii?Q?pBTrk3kSt1MDje4HHnEEaJZGo06QD/2o8I4S8k97UttdCAQaFpBL1vwcGDCb?= =?us-ascii?Q?uzvXsZRTN7OomJZcYLdUxQnndo7fWww9vMjtWxwSZCaQq07XidmuI/EVfZF0?= =?us-ascii?Q?RMTbYywNSHCKnn+QA5+AyLTLs1jX2X4dxdoXeyr/ziwDkFw9a/UDziE1V39X?= =?us-ascii?Q?jXdzOYOgQxo397ANFCtnXNMKib6YwQv2mrfayibkDZ8BRageKVM2m4tFoXck?= =?us-ascii?Q?zUFF64YVbpp7qRA4aCYWq98I?= 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)(35042699022)(1800799024)(376014)(82310400026); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Oct 2024 00:11:24.8707 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a315622c-9e15-42f8-43cb-08dce9893e92 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: AMS0EPF0000019E.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9935 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: Thursday, October 10, 2024 11:54 AM > To: Wathsala Wathawana Vithanage ; > dev@dpdk.org > Cc: Honnappa Nagarahalli ; > jerinj@marvell.com; drc@linux.ibm.com; nd ; nd > > 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 // re= lated 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 // r= elated armv8 instructions > > > > > > -------------------- = ---------------------------------- > ---- > > > > > > head.atomic_load(relaxed) // ldr[head] > > > > > > atomic_thread_fence(acquire) // dmb ish > > > > > > opposite_tail.atomic_load(acquire) // lda[opposite_tai= l] > > > > > > ... > > > > > > 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 // r= elated armv8 instructions > > > > > > -------------------- = ---------------------------------- > ---- > > > > > > head.atomic_load(acquire) // lda [head] > > > > > > opposite_tail.load() // ldr = [opposite_tail] > > > > > > ... > > > > > > head.atomic_cas(..., acquire) // ldaex[head]= ; ... strex[head] > > > > > > > > > > > > The questions that arose from these observations: > > > > > > a) are all 3 approaches equivalent in terms of functionality? > > > > > Different, lda (Load with acquire semantics) and ldr (load) are d= ifferent. > > > > > > > > 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 >=20 > Ok, that is crystal clear, thanks for explanation. >=20 >=20 > > 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. >=20 > Ok. >=20 > > 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. >=20 > 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]? >=20 > Actually, we probably need to look at whole picture: >=20 > 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 >=20 > ldr [prod.head] > dmb ishld > ldr [cons.tail] > ... > /* cas */ > ldrex [prod.head] > stlex [prod.head] /* sink barrier */ >=20 > 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 >=20 > 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 > So, in _genereic_ we don't have that extra hoist barrier after load[con.t= ail], but > we have extra sink barrier at cas(prod.tail). >=20 You are right, technically, that lda[cons.tail] is not required because due= to the=20 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=20 __atomic_load_n(prod.head, __ATOMIC_ACQUIRE); The compiler is then supposed to figure out if there are any dependencies i= n 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 the prod.head. If not, the compiler is supposed to add required barrier to ensure that ord= er is=20 preserved. However, it's easier said than done. No, compiler implements it and C11 sta= ndard discourages use of memory-order-consume for that reason. This brings us to the next caveat. As per C11 standard, there cannot be a f= ree standing Store with release semantics (stlr) that isn't paired with a load with acq= uire or consume semantics. Since we can't use __ATOMIC_CONSUME (which would have resulted i= n=20 ldr[prod.head]), we are forced to use __ATOMIC_ACQUIRE (which results in ld= a[prod.head]). > If that's correct observation, can we change _c11_ implementation to matc= h > _generic_ one by: >=20 > atomic_load(prod.head, releaxed); > atomic_thread_fence(acquire); > atomic_load(cons.tail, releaxed); > .... > atomic_cas(prod.head, release, relaxed); ? >=20 > 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. >=20 They both are functionally correct. _generic is correct but does not comply with the C11 specification.=20 _c11 is correct and fully compliant with the C11 specification. Replacing atomic_load(cons.tail, acquire) with load(cons.tail, relaxed) in _c11 would make it non-compliant with C11 the spec. =20