From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6832AA0350; Sun, 28 Jun 2020 19:34:03 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 04CB01D167; Sun, 28 Jun 2020 19:34:02 +0200 (CEST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40069.outbound.protection.outlook.com [40.107.4.69]) by dpdk.org (Postfix) with ESMTP id C4CFE1C1F4 for ; Sun, 28 Jun 2020 19:34:00 +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=VZmHovuX8EyMB/kQP5LJEI89mCucHQTo/ueLDwEX3BI=; b=lv2jBP3Z/2jYZt5To4w7w2czZyngx1phshbl1/MW2I3giw3Jcuo1i4+YSQclJcsWvYdpVpKzkrY/CujE8suuSPsNCeStyKWq+n8f3CaX0G+rnK+3NehvNSblVPXz6CMdJwU55+DUdVZqYGXuhN/wXPrFQQo0gbcp4LJqAqy4bc0= Received: from AM6PR0202CA0065.eurprd02.prod.outlook.com (2603:10a6:20b:3a::42) by HE1PR0801MB1994.eurprd08.prod.outlook.com (2603:10a6:3:50::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21; Sun, 28 Jun 2020 17:33:58 +0000 Received: from VE1EUR03FT027.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:3a:cafe::25) by AM6PR0202CA0065.outlook.office365.com (2603:10a6:20b:3a::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.24 via Frontend Transport; Sun, 28 Jun 2020 17:33:58 +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=bestguesspass 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 VE1EUR03FT027.mail.protection.outlook.com (10.152.18.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Sun, 28 Jun 2020 17:33:57 +0000 Received: ("Tessian outbound 1e00bf306733:v60"); Sun, 28 Jun 2020 17:33:57 +0000 X-CR-MTA-TID: 64aa7808 Received: from dc1c2cd4b6a5.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id B1922AA1-F35A-4BCA-90A2-B0A5FDD80D9D.1; Sun, 28 Jun 2020 17:33:52 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id dc1c2cd4b6a5.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Sun, 28 Jun 2020 17:33:52 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I346PRqz1qTTnq/tJ7fRxrIhxQhlzDFUKfFEnzXA76pSKbdnuihCsGw2oaIDJ8d9wBln04Dvt7rg3C14Hirz+aJLXZ+698nOMZSrvpXbgEubzLTuVRyRo3WG3j+w44Kjd+qdmpbS2USkYYa2JpTps+9Xk4hifO02uQmq4pV7M8MVPKAOBBCwx1Gx4ft5BdR7CJCTHt0ZFQ+ZLn0PcRFqPLU7hkMJE3iGyVadM20mvBNAVNvaXJTJNW9nPP7Btco6XJsr8Se6+OPDtvDviIa9pes+PXBS77qhZA0y7rOAuhvEXJkj4LRqJjOHNTDwxuBNAs/6xlKpZkASNxtZRTj3ww== 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=VZmHovuX8EyMB/kQP5LJEI89mCucHQTo/ueLDwEX3BI=; b=P3/lxvMQZjSErGeo3ov7V+Y9715kq/P+cejE0jCUIWEr914Hf66lJAzka+53mwcIiBAwCnOT6hVPLlaRgdIwuNOKrT35TmnU1yt1yyoG0evFOYuL+Zl3Ma4RjYKORRGQF42Q78fAORhciSoVjC4lyaz8qpBI0geg/X8TqUO1JnUTnY5RX0f3zaYVCcRs3rIVBXz9zRJ6svsybNiLKNkv+LZXO/aQo9v6xiXHYmgguoCrayem4urST/0IMLZdMt9gM0raPu4jU4zLT1OYM9qY8J9MiYKp5bshfoSNiNC5YS5q2rc2CaYx0kQG+Q5W6RLGvJPkHsrG4v8yaEo5D+5wqg== 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=VZmHovuX8EyMB/kQP5LJEI89mCucHQTo/ueLDwEX3BI=; b=lv2jBP3Z/2jYZt5To4w7w2czZyngx1phshbl1/MW2I3giw3Jcuo1i4+YSQclJcsWvYdpVpKzkrY/CujE8suuSPsNCeStyKWq+n8f3CaX0G+rnK+3NehvNSblVPXz6CMdJwU55+DUdVZqYGXuhN/wXPrFQQo0gbcp4LJqAqy4bc0= Received: from VE1PR08MB4640.eurprd08.prod.outlook.com (2603:10a6:802:b2::11) by VI1PR08MB4541.eurprd08.prod.outlook.com (2603:10a6:803:f9::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.24; Sun, 28 Jun 2020 17:33:45 +0000 Received: from VE1PR08MB4640.eurprd08.prod.outlook.com ([fe80::c2e:9ccb:a690:6863]) by VE1PR08MB4640.eurprd08.prod.outlook.com ([fe80::c2e:9ccb:a690:6863%6]) with mapi id 15.20.3131.026; Sun, 28 Jun 2020 17:33:44 +0000 From: Phil Yang To: "Carrillo, Erik G" , "dev@dpdk.org" CC: "drc@linux.vnet.ibm.com" , Honnappa Nagarahalli , Ruifeng Wang , Dharmik Thakkar , nd Thread-Topic: [dpdk-dev] [PATCH 3/3] eventdev: relax smp barriers with c11 atomics Thread-Index: AQHWQKuOoFq5cth9D0eZxl4zUNwL86jkc1WggAI3MQCAB6eOsA== Date: Sun, 28 Jun 2020 17:33:44 +0000 Message-ID: References: <1591960798-24024-1-git-send-email-phil.yang@arm.com> <1591960798-24024-3-git-send-email-phil.yang@arm.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 07caf074-f65d-44b7-979a-e9a9a9d39dcd.0 x-checkrecipientchecked: true Authentication-Results-Original: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [180.162.1.103] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: d6b3e5f1-941d-462b-ca77-08d81b897035 x-ms-traffictypediagnostic: VI1PR08MB4541:|HE1PR0801MB1994: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:8882; x-forefront-prvs: 0448A97BF2 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: GOOcP781fhA1tefx8E+d19w5ojPJ9Ypzp5A6KpXE8P2AfsDfxoE1wdwV899T0UD1hitziaCRIqMMhJNSMF7oRfbAniv9ELMKs6JPA+T5dD14Cch+NMIUFnP3bWnFq4Y1embEy/aKCPk5dHY/umCbOgaiDthupT0d7ydHsQ13EEeARfJLYUvn/BT+lRycpom9fkRzimTwh6Ei0+Q83S4/V7zuFXoCYj1Z3ap4WxMXO5EGMKJIFjnxhz1sEZ+E/4MI8PZgHAFRJKtikQeD1b3wirIn46tvuTQ2qe4Cyp4KuWynSub4qyGlwhCvbKm/3jUrggHks4KLn0BYyG2wicV2zA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VE1PR08MB4640.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39850400004)(366004)(376002)(346002)(396003)(136003)(6506007)(52536014)(4326008)(54906003)(478600001)(110136005)(33656002)(316002)(8676002)(8936002)(2906002)(55016002)(76116006)(186003)(86362001)(26005)(83380400001)(71200400001)(64756008)(66556008)(66476007)(5660300002)(7696005)(53546011)(9686003)(66446008)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: mmwvCAr05+WnEazwZs3obz95lhBXCbmMy4CM3GjWfjxdSRu6Wn7s4UZbgqenmaRTdIvLdw+7j3o9vxOfRJKI+T5a6czX9OJCuc5yqtdNFMoDJMAhUgXm0ZMeHpRXxfOPtdGFzl0Wnddu36K6TS1poPqELZPjo/7N5ZhhhgSdPoCJKubJNv3W79dXBd4D3WxkPcb6N2iO9W34qZXW46wheG5VCa8cgYpDcv6GyTRWBJxh48n9utcJSFNhe8Tkac7N7VZ/hyXe0nh+MDkXlZW4ooT4HNmcqsmhA1zT/YtT6J3ISBYjXbNGaVDGmoHf4NmPPdDrrHKsU/CNLuQ5unArKXYoK31rVr5Ku+Qvfl6q5dptdeO3CIVdUoEm+3WvUwxHjNiB4LDhg6Yeec/lQ3/qSQ8W1CZlL4saJz2AfFRcWrxKbw1Q4bRwRD67tTqOCJ+qbVCWzeLn+d2Ik8nxz0QOIYPKh1inhPOApDNu2gb98Qo= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB4541 Original-Authentication-Results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT027.eop-EUR03.prod.protection.outlook.com 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; SFTY:; SFS:(4636009)(396003)(346002)(376002)(136003)(39850400004)(46966005)(52536014)(4326008)(110136005)(478600001)(5660300002)(54906003)(316002)(36906005)(8936002)(8676002)(55016002)(26005)(9686003)(186003)(336012)(6506007)(53546011)(70586007)(82740400003)(86362001)(7696005)(356005)(81166007)(82310400002)(83380400001)(33656002)(2906002)(70206006)(47076004); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 4988fc18-d16c-4e3a-08ce-08d81b89686e X-Forefront-PRVS: 0448A97BF2 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: k+fVlnoUzcjIOpcc/bqQcVQOUxSrKU5LylYAZiXX+zaXdMFtxpEiaBVFr49vIUW6ze8eRZuWFJGjmoY7Sf5aoxfixTMEUq2wvZSq2g9uxbeOInQm5X3+EfR+he3+kI3/nXgOt8rHWrU/8AYf8I4WigHLXEqmWgApJKR7rjoN5Esqujc7MHDS0MUxi4QMymLnnHyhnt2T2KKBajx0OxgfktRy8lkg3U4TTD7lxga2jtL6F/YCfqv4rvDE/nYqBpXTFwhRJtcRyBtHC2ggzChllwKHBMXx6bgDm+OqqL3we+Rrv/dne2TgeLHjAh4JfKUAKB9j4JKKwaZb9sFmP+RGxZFrhbwOvpm9zIsCLm2IbdgBBl/iZnHXHrY5T6timcx4EqCJc1LVUdIPOLBc9N/e9Q== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jun 2020 17:33:57.8458 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d6b3e5f1-941d-462b-ca77-08d81b897035 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: VE1EUR03FT027.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1994 Subject: Re: [dpdk-dev] [PATCH 3/3] eventdev: relax smp barriers with c11 atomics 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" Hi Erick, > -----Original Message----- > From: Carrillo, Erik G > Sent: Wednesday, June 24, 2020 3:39 AM > To: Phil Yang ; dev@dpdk.org > Cc: drc@linux.vnet.ibm.com; Honnappa Nagarahalli > ; Ruifeng Wang > ; Dharmik Thakkar ; > nd > Subject: RE: [dpdk-dev] [PATCH 3/3] eventdev: relax smp barriers with c11 > atomics >=20 > Hi Phil, >=20 > Comment in-line: >=20 > > -----Original Message----- > > From: Phil Yang > > Sent: Monday, June 22, 2020 5:12 AM > > To: Phil Yang ; dev@dpdk.org; Carrillo, Erik G > > > > Cc: drc@linux.vnet.ibm.com; Honnappa Nagarahalli > > ; Ruifeng Wang > > ; Dharmik Thakkar > > ; nd > > Subject: RE: [dpdk-dev] [PATCH 3/3] eventdev: relax smp barriers with c= 11 > > atomics > > > > > -----Original Message----- > > > From: dev On Behalf Of Phil Yang > > > Sent: Friday, June 12, 2020 7:20 PM > > > To: dev@dpdk.org; erik.g.carrillo@intel.com > > > Cc: drc@linux.vnet.ibm.com; Honnappa Nagarahalli > > > ; Ruifeng Wang > > ; > > > Dharmik Thakkar ; nd > > > Subject: [dpdk-dev] [PATCH 3/3] eventdev: relax smp barriers with c11 > > > atomics > > > > > > The implementation-specific opaque data is shared between arm and > > > cancel operations. The state flag acts as a guard variable to make > > > sure the update of opaque data is synchronized. This patch uses c11 > > > atomics with explicit one way memory barrier instead of full barriers > > > rte_smp_w/rmb() to synchronize the opaque data between timer arm > and > > cancel threads. > > > > > > Signed-off-by: Phil Yang > > > Reviewed-by: Dharmik Thakkar > > > Reviewed-by: Ruifeng Wang > > > --- > > > lib/librte_eventdev/rte_event_timer_adapter.c | 55 > > > ++++++++++++++++++--------- > > > lib/librte_eventdev/rte_event_timer_adapter.h | 2 +- > > > 2 files changed, 38 insertions(+), 19 deletions(-) > > > > > > diff --git a/lib/librte_eventdev/rte_event_timer_adapter.c > > > b/lib/librte_eventdev/rte_event_timer_adapter.c > > > index 6947efb..0a26501 100644 > > > --- a/lib/librte_eventdev/rte_event_timer_adapter.c > > > +++ b/lib/librte_eventdev/rte_event_timer_adapter.c > > > @@ -629,7 +629,8 @@ swtim_callback(struct rte_timer *tim) > > > sw->expired_timers[sw->n_expired_timers++] =3D tim; > > > sw->stats.evtim_exp_count++; > > > > > > - evtim->state =3D RTE_EVENT_TIMER_NOT_ARMED; > > > + __atomic_store_n(&evtim->state, > > > RTE_EVENT_TIMER_NOT_ARMED, > > > + __ATOMIC_RELEASE); > > > } > > > > > > if (event_buffer_batch_ready(&sw->buffer)) { @@ -1020,6 +1021,7 > > @@ > > > __swtim_arm_burst(const struct rte_event_timer_adapter *adapter, > > > int n_lcores; > > > /* Timer is not armed state */ > > > int16_t exp_state =3D 0; > > > + enum rte_event_timer_state n_state; > > > > > > #ifdef RTE_LIBRTE_EVENTDEV_DEBUG > > > /* Check that the service is running. */ @@ -1060,30 +1062,36 @@ > > > __swtim_arm_burst(const struct rte_event_timer_adapter *adapter, > > > } > > > > > > for (i =3D 0; i < nb_evtims; i++) { > > > - /* Don't modify the event timer state in these cases */ > > > - if (evtims[i]->state =3D=3D RTE_EVENT_TIMER_ARMED) { > > > + n_state =3D __atomic_load_n(&evtims[i]->state, > > > __ATOMIC_RELAXED); > > > + if (n_state =3D=3D RTE_EVENT_TIMER_ARMED) { > > > rte_errno =3D EALREADY; > > > break; > > > - } else if (!(evtims[i]->state =3D=3D > > > RTE_EVENT_TIMER_NOT_ARMED || > > > - evtims[i]->state =3D=3D > > > RTE_EVENT_TIMER_CANCELED)) { > > > + } else if (!(n_state =3D=3D RTE_EVENT_TIMER_NOT_ARMED || > > > + n_state =3D=3D RTE_EVENT_TIMER_CANCELED)) { > > > rte_errno =3D EINVAL; > > > break; > > > } > > > > > > ret =3D check_timeout(evtims[i], adapter); > > > if (unlikely(ret =3D=3D -1)) { > > > - evtims[i]->state =3D > > > RTE_EVENT_TIMER_ERROR_TOOLATE; > > > + __atomic_store_n(&evtims[i]->state, > > > + > > RTE_EVENT_TIMER_ERROR_TOOLATE, > > > + __ATOMIC_RELAXED); > > > rte_errno =3D EINVAL; > > > break; > > > } else if (unlikely(ret =3D=3D -2)) { > > > - evtims[i]->state =3D > > > RTE_EVENT_TIMER_ERROR_TOOEARLY; > > > + __atomic_store_n(&evtims[i]->state, > > > + > > > RTE_EVENT_TIMER_ERROR_TOOEARLY, > > > + __ATOMIC_RELAXED); > > > rte_errno =3D EINVAL; > > > break; > > > } > > > > > > if (unlikely(check_destination_event_queue(evtims[i], > > > adapter) < 0)) { > > > - evtims[i]->state =3D RTE_EVENT_TIMER_ERROR; > > > + __atomic_store_n(&evtims[i]->state, > > > + RTE_EVENT_TIMER_ERROR, > > > + __ATOMIC_RELAXED); > > > rte_errno =3D EINVAL; > > > break; > > > } > > > @@ -1099,13 +1107,18 @@ __swtim_arm_burst(const struct > > > rte_event_timer_adapter *adapter, > > > SINGLE, lcore_id, NULL, evtims[i]); > > > if (ret < 0) { > > > /* tim was in RUNNING or CONFIG state */ > > > - evtims[i]->state =3D RTE_EVENT_TIMER_ERROR; > > > + __atomic_store_n(&evtims[i]->state, > > > + RTE_EVENT_TIMER_ERROR, > > > + __ATOMIC_RELEASE); > > > break; > > > } > > > > > > - rte_smp_wmb(); > > > EVTIM_LOG_DBG("armed an event timer"); > > > - evtims[i]->state =3D RTE_EVENT_TIMER_ARMED; > > > + /* RELEASE ordering guarantees the adapter specific value > > > + * changes observed before the update of state. > > > + */ > > > + __atomic_store_n(&evtims[i]->state, > > > RTE_EVENT_TIMER_ARMED, > > > + __ATOMIC_RELEASE); > > > } > > > > > > if (i < nb_evtims) > > > @@ -1132,6 +1145,7 @@ swtim_cancel_burst(const struct > > > rte_event_timer_adapter *adapter, > > > struct rte_timer *timp; > > > uint64_t opaque; > > > struct swtim *sw =3D swtim_pmd_priv(adapter); > > > + enum rte_event_timer_state n_state; > > > > > > #ifdef RTE_LIBRTE_EVENTDEV_DEBUG > > > /* Check that the service is running. */ @@ -1143,16 +1157,18 @@ > > > swtim_cancel_burst(const struct rte_event_timer_adapter *adapter, > > > > > > for (i =3D 0; i < nb_evtims; i++) { > > > /* Don't modify the event timer state in these cases */ > > > - if (evtims[i]->state =3D=3D RTE_EVENT_TIMER_CANCELED) { > > > + /* ACQUIRE ordering guarantees the access of > > > implementation > > > + * specific opague data under the correct state. > > > + */ > > > + n_state =3D __atomic_load_n(&evtims[i]->state, > > > __ATOMIC_ACQUIRE); > > > + if (n_state =3D=3D RTE_EVENT_TIMER_CANCELED) { > > > rte_errno =3D EALREADY; > > > break; > > > - } else if (evtims[i]->state !=3D RTE_EVENT_TIMER_ARMED) { > > > + } else if (n_state !=3D RTE_EVENT_TIMER_ARMED) { > > > rte_errno =3D EINVAL; > > > break; > > > } > > > > > > - rte_smp_rmb(); > > > - > > > opaque =3D evtims[i]->impl_opaque[0]; > > > timp =3D (struct rte_timer *)(uintptr_t)opaque; > > > RTE_ASSERT(timp !=3D NULL); > > > @@ -1166,11 +1182,14 @@ swtim_cancel_burst(const struct > > > rte_event_timer_adapter *adapter, > > > > > > rte_mempool_put(sw->tim_pool, (void **)timp); > > > > > > - evtims[i]->state =3D RTE_EVENT_TIMER_CANCELED; > > > + __atomic_store_n(&evtims[i]->state, > > > RTE_EVENT_TIMER_CANCELED, > > > + __ATOMIC_RELAXED); > > > evtims[i]->impl_opaque[0] =3D 0; > > > evtims[i]->impl_opaque[1] =3D 0; > > > > Is that safe to remove impl_opaque cleanup above? > > > > Once the soft timer canceled, the __swtim_arm_burst cannot access these > > two fields under the RTE_EVENT_TIMER_CANCELED state. > > After new timer armed, it refills these two fields in the __swtim_arm_b= urst > > thread, which is the only producer of these two fields. > > I think the only risk is that the values of these two field might be un= know > > after swtim_cancel_burst. > > So it should be safe to remove them if no other thread access them afte= r > > canceling the timer. > > > > Any comments on this? > > If we remove these two instructions, we can also remove the > > __atomic_thread_fence below to save performance penalty. > > > > Thanks, > > Phil > > >=20 > In this case, I see the fence as (more importantly) ensuring the state up= date > is visible to other threads... do I misunderstand? I suppose we could a= lso > update the state with an __atomic_store(..., __ATOMIC_RELEASE), but > perhaps that roughly equivalent? Yeah. In my understanding, the fence ensures the state and the implementati= on-specific opaque data update are visible between other timer arm and canc= el threads. Actually, we only care about the state's value here.=20 The atomic RELEASE can also make sure all writes in the current thread are = visible in other threads that acquire the same atomic variable.=20 So I think we can remove the fence and update the state with RELEASE then l= oad the state with ACQUIRE in the timer arm and the cancel threads to achie= ve the same goal. >=20 > > > - > > > - rte_smp_wmb(); > > > + /* The RELEASE fence make sure the clean up > > > + * of opaque data observed between threads. > > > + */ > > > + __atomic_thread_fence(__ATOMIC_RELEASE); > > > } > > > > > > return i; > > > diff --git a/lib/librte_eventdev/rte_event_timer_adapter.h > > > b/lib/librte_eventdev/rte_event_timer_adapter.h > > > index d2ebcb0..6f64b90 100644 > > > --- a/lib/librte_eventdev/rte_event_timer_adapter.h > > > +++ b/lib/librte_eventdev/rte_event_timer_adapter.h > > > @@ -467,7 +467,7 @@ struct rte_event_timer { > > > * - op: RTE_EVENT_OP_NEW > > > * - event_type: RTE_EVENT_TYPE_TIMER > > > */ > > > - volatile enum rte_event_timer_state state; > > > + enum rte_event_timer_state state; > > > /**< State of the event timer. */ > > > uint64_t timeout_ticks; > > > /**< Expiry timer ticks expressed in number of *timer_ticks_ns* > > from > > > -- > > > 2.7.4