From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140055.outbound.protection.outlook.com [40.107.14.55]) by dpdk.org (Postfix) with ESMTP id 76D6E1DA4 for ; Sat, 9 Mar 2019 00:48:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LVTBOnAajz+Z8rubzRNp6corwtW/ufsG82Ow/y3PrIU=; b=Qg4g+yodYIowaU0IboBz5l4PX21pLfNXh8q/F/xDeJOu/0JQ++fqSQJpQcf+BGhTSPTqE9rBkGmRJlHtkxBoAI/NCzyIbKRj+EslfrFP78JlPr5pnz4iIJZqY/QoXR6kY3yj1rreeBjxw2OJn62IWiVp+9mtmGCbruTxlX+lfEU= Received: from AM6PR08MB3672.eurprd08.prod.outlook.com (20.177.115.76) by AM6PR08MB3766.eurprd08.prod.outlook.com (20.178.88.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18; Fri, 8 Mar 2019 23:48:00 +0000 Received: from AM6PR08MB3672.eurprd08.prod.outlook.com ([fe80::4d90:78f1:e670:14d5]) by AM6PR08MB3672.eurprd08.prod.outlook.com ([fe80::4d90:78f1:e670:14d5%3]) with mapi id 15.20.1686.019; Fri, 8 Mar 2019 23:48:00 +0000 From: Honnappa Nagarahalli To: "thomas@monjalon.net" , "Ananyev, Konstantin" , "Gavin Hu (Arm Technology China)" CC: Ilya Maximets , "dev@dpdk.org" , nd , "jerinj@marvell.com" , "hemant.agrawal@nxp.com" , "Nipun.gupta@nxp.com" , "olivier.matz@6wind.com" , "Richardson, Bruce" , "chaozhu@linux.vnet.ibm.com" , nd Thread-Topic: [PATCH v2] ring: enforce reading the tails before ring operations Thread-Index: AQHU1LF2/U32CtPzl0aCGaPiZ5eq9qYBI6cAgACCgsCAADDbAIAACfEwgACACQCAAAFI0A== Date: Fri, 8 Mar 2019 23:48:00 +0000 Message-ID: References: <1551841661-42892-1-git-send-email-gavin.hu@arm.com> <2601191342CEEE43887BDE71AB9772580136556F40@irsmsx105.ger.corp.intel.com> <2456717.RLOWIjrx09@xps> In-Reply-To: <2456717.RLOWIjrx09@xps> 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=Honnappa.Nagarahalli@arm.com; x-originating-ip: [217.140.111.135] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 010d000c-13e6-4cf0-39ed-08d6a4207f7a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:AM6PR08MB3766; x-ms-traffictypediagnostic: AM6PR08MB3766: x-ld-processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr nodisclaimer: True x-microsoft-exchange-diagnostics: 1; AM6PR08MB3766; 20:BWVL/PS4usyyt/tjJuVGu04MVRB7KZl5SMCZ7vdELz8FDxUI/oMB4Yr5dseXyLyAWCqN+vmVumoYBpXu8XX5iDIkFwz3Hk+lEzhsmnO8l3qNLz7kADuHhmiY/K2ZCrZr5LvrDuR8rPg1UhnJpsUjiPl8vg9hVsj6TC4pdB2qBgg= x-microsoft-antispam-prvs: x-forefront-prvs: 0970508454 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(136003)(396003)(376002)(366004)(189003)(199004)(52314003)(51444003)(99286004)(8676002)(7416002)(71200400001)(106356001)(81156014)(105586002)(81166006)(229853002)(2501003)(5660300002)(86362001)(478600001)(72206003)(76176011)(486006)(53936002)(25786009)(52536013)(6436002)(316002)(102836004)(55016002)(4326008)(71190400001)(93886005)(54906003)(110136005)(2906002)(97736004)(26005)(9686003)(476003)(11346002)(66066001)(74316002)(446003)(6246003)(305945005)(7736002)(33656002)(14454004)(6636002)(256004)(68736007)(14444005)(7696005)(6116002)(3846002)(186003)(8936002)(6506007)(21314003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3766; H:AM6PR08MB3672.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: wx2XqWiMwNxEe4q7ZQfzReQhdJZmLzUobnpdoi9eLOGqJUttsL7LyGxlvKY188yZeKjNOCO8QzhwQVPOfyo8bAynO7pbmpgiatonCvmyFtuTiw0H620ky6BJFDuMCHj75qpN30f4NcTZCww8/WlMf6bENkU4KRWStd3lynBJVovnxxCkN4hRGc+uF1ElC6uSgBZfnaUJaKGYbhKMYcHZr+fSZDrzHXDzezMClnvitjJ9Rq8KFNpDhZWkBII0z+M8uz3w4xeVHftptXfuT8N7C07OOWp6WuQZ2MfWwyg1bEow3bD6HId0xcT2dFHlocz+GMxgPXz3KawC+GF/jJ5W9zsGZ8urv2y1TQIzwM8WUwD3it3Ecmrk50hhgvJ3ZBlIbbWGkwTT2FXHpFRg9nU4JAP14oxE1z52nNJANxI1a8Y= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 010d000c-13e6-4cf0-39ed-08d6a4207f7a X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2019 23:48:00.3098 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3766 Subject: Re: [dpdk-dev] [PATCH v2] ring: enforce reading the tails before ring operations 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: Fri, 08 Mar 2019 23:48:03 -0000 > 08/03/2019 16:50, Ananyev, Konstantin: > > 08/03/2019 16:05, Gavin Hu (Arm Technology China): > > > Anyway, on x86, smp_rmb, as a compiler barrier, applies to load/store= , not > only load/load. > > > > Yes, that's true, but I think that's happened by coincidence, not > > intentionally. > > > > > This is the case also for arm, arm64, ppc32, ppc64. > > > I will submit a patch to expand the definition of this API. > > > > I understand your intention, but that does mean we would also need to > > change not only rte_smp_rmb() but rte_rmb() too (to keep things consist= ent)? > > That sounds worring. > > Might be better to keep smp_rmb() definition as it is, and introduce > > new function that fits your purposes (smp_rwmb or smp_load_store_barrie= r)? Looking at rte_rmb, rte_io_rmb, rte_cio_rmb implementations for Arm, they a= ll provide load/store barrier as well. If other architectures also provide = load/store barrier with rte_xxx_rmb, then we could extend the meaning of th= e existing APIs. Even if a new API is provided, we need to do provide the same APIs for IO a= nd CIO variants. >=20 > How is it managed in other projects? In my experience, I usually have been changing the algorithms to use C11 me= mory model. So, I have not come across this issue yet. Others can comment. >=20