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 25659A0599; Fri, 10 Apr 2020 06:39:47 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 622391D449; Fri, 10 Apr 2020 06:39:46 +0200 (CEST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70042.outbound.protection.outlook.com [40.107.7.42]) by dpdk.org (Postfix) with ESMTP id 8A3541D415 for ; Fri, 10 Apr 2020 06:39:44 +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=aqaL2GwksOKrzim8GYizCKbUD4iuZRvOc8rJhaHIz0k=; b=00krP7mSzct126m/dYdAQEvmDto9edU+yqYLCpV6CHZb8Vp8YX41FdFCW18WvaQ5cUNrS6sBbUufL4obe3nkV/apIRtDQQvEY/RGaYAdVbHiVtMXfYqSikP3PyG8/zqaxdweda2m0H3rd3VuKVz+DJxMuGr6T3u5BZ2Br5ObV7w= Received: from DB7PR03CA0107.eurprd03.prod.outlook.com (2603:10a6:10:72::48) by DB8PR08MB5036.eurprd08.prod.outlook.com (2603:10a6:10:ed::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.17; Fri, 10 Apr 2020 04:39:42 +0000 Received: from DB5EUR03FT004.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:72:cafe::a6) by DB7PR03CA0107.outlook.office365.com (2603:10a6:10:72::48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend Transport; Fri, 10 Apr 2020 04:39:42 +0000 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 DB5EUR03FT004.mail.protection.outlook.com (10.152.20.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend Transport; Fri, 10 Apr 2020 04:39:42 +0000 Received: ("Tessian outbound 1425309d4c0b:v50"); Fri, 10 Apr 2020 04:39:42 +0000 X-CR-MTA-TID: 64aa7808 Received: from 192f90d400a8.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 6102108F-008B-454E-8F12-91F49710C9AC.1; Fri, 10 Apr 2020 04:39:37 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 192f90d400a8.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 10 Apr 2020 04:39:37 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iCAWnRyU/2HE7VJKB31tRJHj1ZdVWqowietnei5hn8MisugDgCBO3pYTDUXYVLV3B8PQsGw5yv3sHZFrnqZ3Y4LNKXLIjyysWpD5zpuxMWiq8usxYz7Lj47PW6p1NHhMXKtRb+jtRuuuVobpRatzKezpF/lmJ+uxLoEzg7SdZfeCukwu+bdSiHLfJn0XTo7HrD7417a4p50jvRMLguhjILedPoTmsjZt3trUweY1IOYrs3c0ecVqL1/u3/FrPKAfr42j78VL9U+vSaf46zmd6/Oy60Lp4V38K5TqAlfd9oEQpJGWRVmuYCiZRWYKV1iSzUKAqt2RZi3pa3xnpQpQTQ== 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=aqaL2GwksOKrzim8GYizCKbUD4iuZRvOc8rJhaHIz0k=; b=W+WYn+Ki73cNPUfuKF2j6WFuGeHH2gJAZKfHSYdWLoCIOEdMKSaqRSRoUfIh89/8IQjJH/vccWSB9Esn58ivejWdII5ZcPc4SX92QNz9iKOV7BaAAHMGvNg6XkFRV7wY2mN3wN2yBE7nLv/FTcqum+KQ0YBw7H4yR9hb8ixNDhSDScFJlnhFaFsmyU/SU3Fd5KYHdMULK/VhDNH8r0BbFBedpsyIYDNfZDvLvwJ0lzchg+mPZYltqMWgU3PsyCT0fTF75ZFMstJ2eVcVziztUEYPZHzPb+Sa5O4es7fPVEeTSlLz0z2HoCrKNDNlVM429WrDMMUYGnpPBHW5dXOVrg== 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=aqaL2GwksOKrzim8GYizCKbUD4iuZRvOc8rJhaHIz0k=; b=00krP7mSzct126m/dYdAQEvmDto9edU+yqYLCpV6CHZb8Vp8YX41FdFCW18WvaQ5cUNrS6sBbUufL4obe3nkV/apIRtDQQvEY/RGaYAdVbHiVtMXfYqSikP3PyG8/zqaxdweda2m0H3rd3VuKVz+DJxMuGr6T3u5BZ2Br5ObV7w= Received: from VE1PR08MB4640.eurprd08.prod.outlook.com (10.255.27.75) by VE1PR08MB5021.eurprd08.prod.outlook.com (20.179.30.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Fri, 10 Apr 2020 04:39:35 +0000 Received: from VE1PR08MB4640.eurprd08.prod.outlook.com ([fe80::7df3:e3c8:54f7:57c2]) by VE1PR08MB4640.eurprd08.prod.outlook.com ([fe80::7df3:e3c8:54f7:57c2%6]) with mapi id 15.20.2878.021; Fri, 10 Apr 2020 04:39:35 +0000 From: Phil Yang To: "Carrillo, Erik G" , Honnappa Nagarahalli , "rsanford@akamai.com" , "dev@dpdk.org" CC: "david.marchand@redhat.com" , "Burakov, Anatoly" , "thomas@monjalon.net" , "jerinj@marvell.com" , "hemant.agrawal@nxp.com" , Gavin Hu , nd , nd , nd Thread-Topic: [PATCH 2/2] lib/timer: relax barrier for status update Thread-Index: AQHV6t2eFNsTow5NnU2kr/yq0gxiTahv/n8AgAABooCAAALBAIAACHIAgAFpM4CAAJZ+8A== Date: Fri, 10 Apr 2020 04:39:35 +0000 Message-ID: References: <1582526539-14360-1-git-send-email-phil.yang@arm.com> <1582526539-14360-2-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: d54d0307-370b-44e5-8c04-5298dcf98510.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Phil.Yang@arm.com; x-originating-ip: [113.29.88.7] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 68b073a1-8b22-460d-2b64-08d7dd093001 x-ms-traffictypediagnostic: VE1PR08MB5021:|VE1PR08MB5021:|DB8PR08MB5036: x-ld-processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:7691;OLM:7691; x-forefront-prvs: 0369E8196C 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:(10009020)(4636009)(39860400002)(376002)(346002)(136003)(366004)(396003)(5660300002)(6506007)(110136005)(86362001)(4326008)(54906003)(53546011)(7696005)(15650500001)(55236004)(186003)(71200400001)(8936002)(76116006)(52536014)(316002)(8676002)(9686003)(55016002)(66446008)(33656002)(66556008)(81156014)(66946007)(64756008)(2906002)(66476007)(478600001)(26005); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: wlwaGv3NvHCKmZWT7gWp6UHQIHbbpDoo5FCl4Z9OJ0TrE0LcP6xYeb0TUOldeoy0aJVuzPzqCZiSumQWf+clzCInBFcTI90effY3EIQ6IeZiOGP6eNkiaMbEU9dtSmDP6v66cQXTAIKQuiatGFNmrBA1htGQFBpgL1WEK3hg5UkHFaCKf3tYo4eST1AWycoLNivhaXW0MVeIqfzEB/fqBDGBJnRo2JhXmX7+GqnFRBGuMc/WMjPAqBcCUd+56+xCO1EMAkYVj6aGCImlke4LsDfACUuVmJaZHq6SUqyVQhsGEbtM5+zh+cHjhArpdR55p3azveZKRG1jL6HP51U1BOgh+d+EBV52ihv4kVsDpJNoYeCNcs27kgwxz/MDTsVIn4IdZccdfsaQHtRfaR21yGJiRdEnHL9YM2YV13LxRWldTO3h+b8UnqCzAhZrnVwN x-ms-exchange-antispam-messagedata: gb2AwqhXWSgoWkP/W6hwQojraPBANFW4Xi+nPPB+TYQQpTVMoj7upvLmkusqIqeAgzk2GIgHv9XmaepIngT8MHSTJ1W/4KXtwpexT/5Wu4XWVw0oHYLmyD4WYrS0FK0N6kLN4X40N8t4d1wm7TdybA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5021 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Phil.Yang@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT004.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:(10009020)(4636009)(376002)(346002)(396003)(39860400002)(136003)(46966005)(47076004)(15650500001)(52536014)(86362001)(54906003)(81166007)(55016002)(9686003)(70206006)(4326008)(316002)(70586007)(7696005)(81156014)(110136005)(82740400003)(5660300002)(8936002)(356005)(186003)(53546011)(6506007)(33656002)(478600001)(336012)(26826003)(26005)(8676002)(2906002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 0bc30a39-9ed1-4edc-609b-08d7dd092be7 X-Forefront-PRVS: 0369E8196C X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: n4qm0cIe4RO1zkv3CoR82nBu3c+CldDuuUDxlLoemTGf436ObrF0jAzu2/x952goThqwf2GUlJIk2C82lOAHp0nkBUoc7bPPr5uS+/tfqPjEbwz3YGxH4plVi0M3qn3eJyF1ehcj6kZuYtZhl1YKLLPFDtnQ+iCRwrMTKZEIq4XVK2qzr3/3BeBD1rOZM8myZuJs9DP/Yv+u+xi3j4mXvwJmCUup2/+aNnY2XD2/KMl2CB4HzzGsB9JDZiGAmnDToKJY9Zy6yTP/m+ex0eIrPQJxmmRi8YS9GD9JucGNxRaGsQJJOCGfrngq4fhpktzhKDrN/RRfigjKWzjlH53y45dZBoog35Y9Gw9LcwJSrPhoDv1n/OGaQO/3HZly88dpDPYqOgzx9Fs22B7pw0eiBDMdACtCKYTik8pStSkHziIVvwAuq5Ac0J0HZv8CZi6t5DFvTVDuVes1ptjveJxbx7w+yU6ogtrH8xa2ovO2OHgISd68AyGNFUmRyhfjq0NuV0R+GT8Akyqerml0F0UElg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Apr 2020 04:39:42.5891 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 68b073a1-8b22-460d-2b64-08d7dd093001 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-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5036 Subject: Re: [dpdk-dev] [PATCH 2/2] lib/timer: relax barrier for status update 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" > -----Original Message----- > From: Carrillo, Erik G > Sent: Friday, April 10, 2020 3:29 AM > To: Honnappa Nagarahalli ; Phil Yang > ; rsanford@akamai.com; dev@dpdk.org > Cc: david.marchand@redhat.com; Burakov, Anatoly > ; thomas@monjalon.net; jerinj@marvell.com; > hemant.agrawal@nxp.com; Gavin Hu ; nd > ; nd > Subject: RE: [PATCH 2/2] lib/timer: relax barrier for status update >=20 > > -----Original Message----- > > From: Honnappa Nagarahalli > > Sent: Wednesday, April 8, 2020 4:56 PM > > To: Carrillo, Erik G ; Phil Yang > > ; rsanford@akamai.com; dev@dpdk.org > > Cc: david.marchand@redhat.com; Burakov, Anatoly > > ; thomas@monjalon.net; > jerinj@marvell.com; > > hemant.agrawal@nxp.com; Gavin Hu ; nd > > ; Honnappa Nagarahalli ; > > nd > > Subject: RE: [PATCH 2/2] lib/timer: relax barrier for status update > > > > > > > > > > > > > > > > Subject: [PATCH 2/2] lib/timer: relax barrier for status update > > > > > > > > > > > > Volatile has no ordering semantics. The rte_timer structure > > > > > > defines timer status as a volatile variable and uses the > > > > > > rte_r/wmb barrier to guarantee inter-thread visibility. > > > > > > > > > > > > This patch optimized the volatile operation with c11 atomic > > > > > > operations and one-way barrier to save the performance penalty. > > > > > > According to the timer_perf_autotest benchmarking results, this > > > > > > patch can uplift 10%~16% timer appending performance, 3%~20% > > > > > > timer resetting performance and 45% timer callbacks scheduling > > > > > > performance on aarch64 and no loss in performance for x86. > > > > > > > > > > > > Suggested-by: Honnappa Nagarahalli > > > > > > > > > > > > Signed-off-by: Phil Yang > > > > > > Reviewed-by: Gavin Hu > > > > > > > > > > Hi Phil, > > > > > > > > > > It seems like the consensus is to generally avoid replacing > rte_atomic_* > > > > > interfaces with the GCC builtins directly. In other areas of DP= DK that > > are > > > > > being patched, are the C11 APIs going to be > > investigated? > > > > It > > > > > seems like that decision will apply here as well. > > > > Agree. The new APIs are going to be 1 to 1 mapped with the built-in > > > > intrinsics (the memory orderings used themselves will not change). > > > > We should go ahead with the review and conclude any issues. Once th= e > > > > decision is made on what APIs to use, we can submit the next versio= n > > > > using > > > the APIs decided. > > > > > > > Thanks, Honnappa. > > > > > > I have reviewed the memory orderings and I see no issues with them. = I > do > > > have a question regarding a comment - I'll pose it inline: > > Fantastic, thank you. > > I have an unrelated (to this patch) question for you below. > > > > > > > > > > > > > > > Thanks, > > > > > Erik > > > > > > > > > > > --- > > > > > > lib/librte_timer/rte_timer.c | 90 > > > > > > +++++++++++++++++++++++++++++++---- > > > > > > --------- > > > > > > lib/librte_timer/rte_timer.h | 2 +- > > > > > > 2 files changed, 65 insertions(+), 27 deletions(-) > > > > > > > > > > > > diff --git a/lib/librte_timer/rte_timer.c > > > > > > b/lib/librte_timer/rte_timer.c index 269e921..be0262d 100644 > > > > > > --- a/lib/librte_timer/rte_timer.c > > > > > > +++ b/lib/librte_timer/rte_timer.c > > > > > > @@ -10,7 +10,6 @@ > > > > > > #include > > > > > > #include > > > > > > > > > > > > -#include > > > > > > #include > > > > > > #include > > > > > > #include > > > > > > @@ -218,7 +217,7 @@ rte_timer_init(struct rte_timer *tim) > > > > > > > > > > > > status.state =3D RTE_TIMER_STOP; > > > > > > status.owner =3D RTE_TIMER_NO_OWNER; > > > > > > - tim->status.u32 =3D status.u32; > > > > > > + __atomic_store_n(&tim->status.u32, status.u32, > > > > > > __ATOMIC_RELAXED); > > > > > > } > > > > > > > > > > > > /* >=20 > <... snipped ...> >=20 > > > > > > @@ -258,9 +257,20 @@ timer_set_config_state(struct rte_timer > > *tim, > > > > > > * mark it atomically as being configured */ > > > > > > status.state =3D RTE_TIMER_CONFIG; > > > > > > status.owner =3D (int16_t)lcore_id; > > > > > > - success =3D rte_atomic32_cmpset(&tim->status.u32, > > > > > > - prev_status.u32, > > > > > > - status.u32); > > > > > > + /* If status is observed as RTE_TIMER_CONFIG > > earlier, > > > > > > + * that's not going to cause any issues because the > > > > > > + * pattern is read for status then read the other > > members. > > > > > > I don't follow the above comment. What is meant by "earlier"? > > > > > > Thanks, > > > Erik > > I would rather change this comment to something similar to what is > > mentioned while changing to 'RUNNING' state. > > 'CONFIG' is also a locking state. I think it is much easier to understa= nd. > > >=20 > Ok, thanks - that makes sense. OK, thanks.=20 I will modify the comments in V2 to:=20 "CONFIG states are acting as locked states. If the timer is in CONFIG state= , the state cannot be changed by other threads. So, we should use ACQUIRE here." Thanks, Phil >=20 > < ... snipped ...> >=20 > > > > > > 748,8 +774,12 @@ __rte_timer_manage(struct rte_timer_data > > > > *timer_data) > > > > > > status.state =3D RTE_TIMER_PENDING; > > Is it better to set this to STOPPED since it is out of the run list? I = think it is > > better for the understanding as well. > > >=20 > In this location, we are dealing with periodic timers, and we are about t= o > restart the current timer after it just expired and its callback was exec= uted. > As I understand it, setting the state back to PENDING here will cause the > timer_reset() call below to remove this timer from the list (run list) it= 's still in > (and fix up the links from the previous to the next elements), update oth= er > bits of the data structure, and update stats. That behavior would chang= e if > we set the state to STOPPED. At least to me, it also seems like the PEND= ING > state is still accurate conceptually since the periodic timer wasn't expl= icitly > stopped by this processing. Yes. +1 for this. >=20 > Thanks, > Erik >=20 > > > > > > __TIMER_STAT_ADD(priv_timer, pending, 1); > > > > > > status.owner =3D (int16_t)lcore_id; > > > > > > - rte_wmb(); > > > > > > - tim->status.u32 =3D status.u32; > > > > > > + /* The "RELEASE" ordering guarantees the > > memory > > > > > > + * operations above the status update are > > observed > > > > > > + * before the update by all threads > > > > > > + */ > > > > > > + __atomic_store_n(&tim->status.u32, > > status.u32, > > > > > > + __ATOMIC_RELEASE); > > > > > > __rte_timer_reset(tim, tim->expire + tim- > > >period, > > > > > > tim->period, lcore_id, tim->f, tim- > > >arg, 1, > > > > > > timer_data); > > > > > > @@ -919,8 +949,12 @@ rte_timer_alt_manage(uint32_t > > timer_data_id, > > > > > > /* remove from done list and mark timer as > > stopped > > > > > */ > > > > > > status.state =3D RTE_TIMER_STOP; > > > > > > status.owner =3D RTE_TIMER_NO_OWNER; > > > > > > - rte_wmb(); > > > > > > - tim->status.u32 =3D status.u32; > > > > > > + /* The "RELEASE" ordering guarantees the > > memory > > > > > > + * operations above the status update are > > observed > > > > > > + * before the update by all threads > > > > > > + */ > > > > > > + __atomic_store_n(&tim->status.u32, > > status.u32, > > > > > > + __ATOMIC_RELEASE); > > > > > > } else { > > > > > > /* keep it in list and mark timer as pending */ > > > > > > rte_spinlock_lock( > > > > > > @@ -928,8 +962,12 @@ rte_timer_alt_manage(uint32_t > > timer_data_id, > > > > > > status.state =3D RTE_TIMER_PENDING; > > > > > > __TIMER_STAT_ADD(data->priv_timer, > > pending, 1); > > > > > > status.owner =3D (int16_t)this_lcore; > > > > > > - rte_wmb(); > > > > > > - tim->status.u32 =3D status.u32; > > > > > > + /* The "RELEASE" ordering guarantees the > > memory > > > > > > + * operations above the status update are > > observed > > > > > > + * before the update by all threads > > > > > > + */ > > > > > > + __atomic_store_n(&tim->status.u32, > > status.u32, > > > > > > + __ATOMIC_RELEASE); > > > > > > __rte_timer_reset(tim, tim->expire + tim- > > >period, > > > > > > tim->period, this_lcore, tim->f, tim- > > >arg, 1, > > > > > > data); > > > > > > diff --git a/lib/librte_timer/rte_timer.h > > > > > > b/lib/librte_timer/rte_timer.h index c6b3d45..df533fa 100644 > > > > > > --- a/lib/librte_timer/rte_timer.h > > > > > > +++ b/lib/librte_timer/rte_timer.h > > > > > > @@ -101,7 +101,7 @@ struct rte_timer { > > > > > > uint64_t expire; /**< Time when timer expire. */ > > > > > > struct rte_timer *sl_next[MAX_SKIPLIST_DEPTH]; > > > > > > - volatile union rte_timer_status status; /**< Status of timer. > > */ > > > > > > + union rte_timer_status status; /**< Status of timer. */ > > > > > > uint64_t period; /**< Period of timer (0 if not periodi= c). */ > > > > > > rte_timer_cb_t f; /**< Callback function. */ > > > > > > void *arg; /**< Argument to callback function. */ > > > > > > -- > > > > > > 2.7.4