From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140042.outbound.protection.outlook.com [40.107.14.42]) by dpdk.org (Postfix) with ESMTP id 489A84C8D for ; Mon, 1 Apr 2019 21:06:42 +0200 (CEST) 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=OIE1JQCEeHhj3iSGOK08bE+sxHCFeCiwXkOLvO91T38=; b=JhMhUH+9MhD8qNggc9ED9Y8MR3RyxbYxyLMIShKliV+EabKWOQOmLUckYHpOE3VJlmuUo/e4CnJsAnL9V7Z6YWoaEMKONZwfcYtOqS5G8CvmHaEWTVVJDw0I3V6jDV0iBM9AqRfCZBA4Maf6yiK4VZNMVBg/HDZBj/07tJFTcVA= Received: from VE1PR08MB5149.eurprd08.prod.outlook.com (20.179.30.152) by VE1PR08MB4718.eurprd08.prod.outlook.com (10.255.115.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.15; Mon, 1 Apr 2019 19:06:39 +0000 Received: from VE1PR08MB5149.eurprd08.prod.outlook.com ([fe80::e0ae:ecad:ec5:8177]) by VE1PR08MB5149.eurprd08.prod.outlook.com ([fe80::e0ae:ecad:ec5:8177%2]) with mapi id 15.20.1750.017; Mon, 1 Apr 2019 19:06:39 +0000 From: Honnappa Nagarahalli To: "Eads, Gage" , "'dev@dpdk.org'" CC: "'olivier.matz@6wind.com'" , "'arybchenko@solarflare.com'" , "Richardson, Bruce" , "Ananyev, Konstantin" , "Gavin Hu (Arm Technology China)" , nd , "thomas@monjalon.net" , nd Thread-Topic: [PATCH v3 6/8] stack: add C11 atomic implementation Thread-Index: AQHU1CtbzfcoFG40VUqutGZl2oW8e6Yhl7KggAFxNMCAA4rc0IABN+yg Date: Mon, 1 Apr 2019 19:06:38 +0000 Message-ID: References: <20190305164256.2367-1-gage.eads@intel.com> <20190306144559.391-1-gage.eads@intel.com> <20190306144559.391-7-gage.eads@intel.com> <9184057F7FC11744A2107296B6B8EB1E5420D940@FMSMSX108.amr.corp.intel.com> <9184057F7FC11744A2107296B6B8EB1E5420DDF2@FMSMSX108.amr.corp.intel.com> In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E5420DDF2@FMSMSX108.amr.corp.intel.com> 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: c74920d4-16c2-49bf-737c-08d6b6d52b55 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VE1PR08MB4718; x-ms-traffictypediagnostic: VE1PR08MB4718: x-ms-exchange-purlcount: 2 x-ld-processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr nodisclaimer: True x-microsoft-antispam-prvs: x-forefront-prvs: 0994F5E0C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39860400002)(376002)(136003)(346002)(199004)(189003)(55016002)(53936002)(25786009)(229853002)(81156014)(81166006)(256004)(14454004)(106356001)(72206003)(6246003)(966005)(66066001)(74316002)(6116002)(2906002)(186003)(305945005)(7736002)(71200400001)(5660300002)(71190400001)(68736007)(97736004)(3846002)(52536014)(54906003)(14444005)(76176011)(11346002)(102836004)(316002)(93886005)(99286004)(7696005)(6306002)(478600001)(8936002)(8676002)(446003)(476003)(9686003)(86362001)(486006)(110136005)(6506007)(105586002)(33656002)(4326008)(26005)(6436002)(21314003)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR08MB4718; H:VE1PR08MB5149.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: lE5A9WijzNTcs8nt5aLslZS9udrjGVF9L6AEGXU4J0p2i9dZAdXhAngMiSXlqR9f29RZySbOId7U2TC+7ZZBa5ecTeeXrYW+bdl4N6N0rER7H4rMa7Yai04O7JzPGTKSHm8ic8MO9ZDjcZO0VefqN5OO3sCKqDXXH8oqWSmKJLNNU33BJe/wGLESJOFMWbWtVu9kuW9/+aNRaQtZnSrXFsvLkKCN3M8RcF0gE2N5OUjz6gNCaAJYjHrQKU6mAlz+3CkiXoOtnhyNO4B8eyxdSRoj68jGYcut5++qq3wy2kvkKjI9NHraLbCfsSZvLTRHGF0SEY4wrss/nieliD7uhgr5lvlzMOyS6Sdstai5RGtY1ePcdTCrTacAZJmoV+tcr2Y3X/W2bFH2/9QyKDiwioVzlkaTbZLIDT7+xBEVffM= 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: c74920d4-16c2-49bf-737c-08d6b6d52b55 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2019 19:06:38.9702 (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: VE1PR08MB4718 Subject: Re: [dpdk-dev] [PATCH v3 6/8] stack: add C11 atomic implementation 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: Mon, 01 Apr 2019 19:06:42 -0000 > > Subject: RE: [PATCH v3 6/8] stack: add C11 atomic implementation > > > > [snip] > > > > > > +static __rte_always_inline void > > > > +__rte_stack_lf_push(struct rte_stack_lf_list *list, > > > > + struct rte_stack_lf_elem *first, > > > > + struct rte_stack_lf_elem *last, > > > > + unsigned int num) > > > > +{ > > > > +#ifndef RTE_ARCH_X86_64 > > > > + RTE_SET_USED(first); > > > > + RTE_SET_USED(last); > > > > + RTE_SET_USED(list); > > > > + RTE_SET_USED(num); > > > > +#else > > > > + struct rte_stack_lf_head old_head; > > > > + int success; > > > > + > > > > + old_head =3D list->head; > > > This can be a torn read (same as you have mentioned in > > > __rte_stack_lf_pop). I suggest we use acquire thread fence here as > > > well (please see the comments in __rte_stack_lf_pop). > > > > Agreed. I'll add the acquire fence. > > >=20 > On second thought, an acquire fence isn't necessary. The acquire fence in > __rte_stack_lf_pop() ensures the list->head is ordered before the list el= ement > reads. That isn't necessary here; we need to ensure that the last->next w= rite > occurs (and is observed) before the list->head write, which the CAS's REL= EASE > success memorder accomplishes. >=20 > If a torn read occurs, the CAS will fail and will atomically re-load &old= _head. Following is my understanding: The general guideline is there should be a load-acquire for every store-rel= ease. In both xxx_lf_pop and xxx_lf_push, the head is store-released, hence= the load of the head should be load-acquire. >>From the code (for ex: in function _xxx_lf_push), you can notice that there= is dependency from 'old_head to new_head to list->head(in compare_exchange= )'. When such a dependency exists, if the memory orderings have to be avoid= ed, one needs to use __ATOMIC_CONSUME. Currently, the compilers will use a = stronger memory order (which is __ATOMIC_ACQUIRE) as __ATOMIC_CONSUME is no= t well defined. Please refer to [1] and [2] for more info. IMO, since, for 128b, we do not have a pure load-acquire, I suggest we use = thread_fence with acquire semantics. It is a heavier barrier, but I think i= t is a safer code which will adhere to C11 memory model. [1] https://preshing.com/20140709/the-purpose-of-memory_order_consume-in-cp= p11/ [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0750r1.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 31189A0679 for ; Mon, 1 Apr 2019 21:06:44 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 64E274C90; Mon, 1 Apr 2019 21:06:43 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140042.outbound.protection.outlook.com [40.107.14.42]) by dpdk.org (Postfix) with ESMTP id 489A84C8D for ; Mon, 1 Apr 2019 21:06:42 +0200 (CEST) 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=OIE1JQCEeHhj3iSGOK08bE+sxHCFeCiwXkOLvO91T38=; b=JhMhUH+9MhD8qNggc9ED9Y8MR3RyxbYxyLMIShKliV+EabKWOQOmLUckYHpOE3VJlmuUo/e4CnJsAnL9V7Z6YWoaEMKONZwfcYtOqS5G8CvmHaEWTVVJDw0I3V6jDV0iBM9AqRfCZBA4Maf6yiK4VZNMVBg/HDZBj/07tJFTcVA= Received: from VE1PR08MB5149.eurprd08.prod.outlook.com (20.179.30.152) by VE1PR08MB4718.eurprd08.prod.outlook.com (10.255.115.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.15; Mon, 1 Apr 2019 19:06:39 +0000 Received: from VE1PR08MB5149.eurprd08.prod.outlook.com ([fe80::e0ae:ecad:ec5:8177]) by VE1PR08MB5149.eurprd08.prod.outlook.com ([fe80::e0ae:ecad:ec5:8177%2]) with mapi id 15.20.1750.017; Mon, 1 Apr 2019 19:06:39 +0000 From: Honnappa Nagarahalli To: "Eads, Gage" , "'dev@dpdk.org'" CC: "'olivier.matz@6wind.com'" , "'arybchenko@solarflare.com'" , "Richardson, Bruce" , "Ananyev, Konstantin" , "Gavin Hu (Arm Technology China)" , nd , "thomas@monjalon.net" , nd Thread-Topic: [PATCH v3 6/8] stack: add C11 atomic implementation Thread-Index: AQHU1CtbzfcoFG40VUqutGZl2oW8e6Yhl7KggAFxNMCAA4rc0IABN+yg Date: Mon, 1 Apr 2019 19:06:38 +0000 Message-ID: References: <20190305164256.2367-1-gage.eads@intel.com> <20190306144559.391-1-gage.eads@intel.com> <20190306144559.391-7-gage.eads@intel.com> <9184057F7FC11744A2107296B6B8EB1E5420D940@FMSMSX108.amr.corp.intel.com> <9184057F7FC11744A2107296B6B8EB1E5420DDF2@FMSMSX108.amr.corp.intel.com> In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E5420DDF2@FMSMSX108.amr.corp.intel.com> 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: c74920d4-16c2-49bf-737c-08d6b6d52b55 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VE1PR08MB4718; x-ms-traffictypediagnostic: VE1PR08MB4718: x-ms-exchange-purlcount: 2 x-ld-processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr nodisclaimer: True x-microsoft-antispam-prvs: x-forefront-prvs: 0994F5E0C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39860400002)(376002)(136003)(346002)(199004)(189003)(55016002)(53936002)(25786009)(229853002)(81156014)(81166006)(256004)(14454004)(106356001)(72206003)(6246003)(966005)(66066001)(74316002)(6116002)(2906002)(186003)(305945005)(7736002)(71200400001)(5660300002)(71190400001)(68736007)(97736004)(3846002)(52536014)(54906003)(14444005)(76176011)(11346002)(102836004)(316002)(93886005)(99286004)(7696005)(6306002)(478600001)(8936002)(8676002)(446003)(476003)(9686003)(86362001)(486006)(110136005)(6506007)(105586002)(33656002)(4326008)(26005)(6436002)(21314003)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR08MB4718; H:VE1PR08MB5149.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: lE5A9WijzNTcs8nt5aLslZS9udrjGVF9L6AEGXU4J0p2i9dZAdXhAngMiSXlqR9f29RZySbOId7U2TC+7ZZBa5ecTeeXrYW+bdl4N6N0rER7H4rMa7Yai04O7JzPGTKSHm8ic8MO9ZDjcZO0VefqN5OO3sCKqDXXH8oqWSmKJLNNU33BJe/wGLESJOFMWbWtVu9kuW9/+aNRaQtZnSrXFsvLkKCN3M8RcF0gE2N5OUjz6gNCaAJYjHrQKU6mAlz+3CkiXoOtnhyNO4B8eyxdSRoj68jGYcut5++qq3wy2kvkKjI9NHraLbCfsSZvLTRHGF0SEY4wrss/nieliD7uhgr5lvlzMOyS6Sdstai5RGtY1ePcdTCrTacAZJmoV+tcr2Y3X/W2bFH2/9QyKDiwioVzlkaTbZLIDT7+xBEVffM= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: c74920d4-16c2-49bf-737c-08d6b6d52b55 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2019 19:06:38.9702 (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: VE1PR08MB4718 Subject: Re: [dpdk-dev] [PATCH v3 6/8] stack: add C11 atomic implementation 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190401190638.00viGsh-VUATQbMAvk8BXCsIH-YQhO1_W5_3MQYtjCE@z> > > Subject: RE: [PATCH v3 6/8] stack: add C11 atomic implementation > > > > [snip] > > > > > > +static __rte_always_inline void > > > > +__rte_stack_lf_push(struct rte_stack_lf_list *list, > > > > + struct rte_stack_lf_elem *first, > > > > + struct rte_stack_lf_elem *last, > > > > + unsigned int num) > > > > +{ > > > > +#ifndef RTE_ARCH_X86_64 > > > > + RTE_SET_USED(first); > > > > + RTE_SET_USED(last); > > > > + RTE_SET_USED(list); > > > > + RTE_SET_USED(num); > > > > +#else > > > > + struct rte_stack_lf_head old_head; > > > > + int success; > > > > + > > > > + old_head =3D list->head; > > > This can be a torn read (same as you have mentioned in > > > __rte_stack_lf_pop). I suggest we use acquire thread fence here as > > > well (please see the comments in __rte_stack_lf_pop). > > > > Agreed. I'll add the acquire fence. > > >=20 > On second thought, an acquire fence isn't necessary. The acquire fence in > __rte_stack_lf_pop() ensures the list->head is ordered before the list el= ement > reads. That isn't necessary here; we need to ensure that the last->next w= rite > occurs (and is observed) before the list->head write, which the CAS's REL= EASE > success memorder accomplishes. >=20 > If a torn read occurs, the CAS will fail and will atomically re-load &old= _head. Following is my understanding: The general guideline is there should be a load-acquire for every store-rel= ease. In both xxx_lf_pop and xxx_lf_push, the head is store-released, hence= the load of the head should be load-acquire. >From the code (for ex: in function _xxx_lf_push), you can notice that there= is dependency from 'old_head to new_head to list->head(in compare_exchange= )'. When such a dependency exists, if the memory orderings have to be avoid= ed, one needs to use __ATOMIC_CONSUME. Currently, the compilers will use a = stronger memory order (which is __ATOMIC_ACQUIRE) as __ATOMIC_CONSUME is no= t well defined. Please refer to [1] and [2] for more info. IMO, since, for 128b, we do not have a pure load-acquire, I suggest we use = thread_fence with acquire semantics. It is a heavier barrier, but I think i= t is a safer code which will adhere to C11 memory model. [1] https://preshing.com/20140709/the-purpose-of-memory_order_consume-in-cp= p11/ [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0750r1.html