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 9C64CA0350; Mon, 29 Jun 2020 20:07:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4D9D91BE94; Mon, 29 Jun 2020 20:07:34 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id C378A1B6B4 for ; Mon, 29 Jun 2020 20:07:31 +0200 (CEST) IronPort-SDR: bqSPSmlO+sA0MwbAXxtCyUeEbvuHVDYlGIm1eIJ4vPVyVe+XIQXtMwoz/2krbvmaV0w7vORJgM EhzXZYJsB/2g== X-IronPort-AV: E=McAfee;i="6000,8403,9666"; a="133458362" X-IronPort-AV: E=Sophos;i="5.75,295,1589266800"; d="scan'208";a="133458362" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jun 2020 11:07:30 -0700 IronPort-SDR: jWiGPjj02nkOYXcs/sBq0UwpjW8DuWgtAMaXTzlp8mqRwi0FWoxSJLWiw9cWP6Za1nLNuA0Rxo M+Y3rtkwPPyQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,295,1589266800"; d="scan'208";a="454280590" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by orsmga005.jf.intel.com with ESMTP; 29 Jun 2020 11:07:30 -0700 Received: from orsmsx113.amr.corp.intel.com (10.22.240.9) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 29 Jun 2020 11:07:30 -0700 Received: from ORSEDG001.ED.cps.intel.com (10.7.248.4) by ORSMSX113.amr.corp.intel.com (10.22.240.9) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 29 Jun 2020 11:07:30 -0700 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.106) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 29 Jun 2020 11:07:30 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z6B06qrt8POwWfeGPXV8HUxPz2elZpiyno3St5erbbfgVTBMWBKBFcogQ6OXrvsyqGQOS93+/7iqxvG/2fP+/CJRx7HvriiObAi99uZ6ZPPWG9NTncCuRdZcGHY6yAAb5Z7XVPpxdQUp0tlJmzx/fqMeb+RpVUizlsEPWVoOmkt85LOcmXrTkO0Ewn262GB9Xhw+QK4TDBy/Bha1UXx4O/L2PJ3GRzPXGLxdjGnQHI5TNdJSYYLVG+GWccRmz6WFNXq5n+HkSCdZBfcl/MCDgNXSyRNtxmmAb5xbLM2FRSx+bMj5zKAufAKg1O8ETBEjv+BFkPCu8N+LaWZzNk8fHw== 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=ur7LYKesMy8ZoqMQAUXZuUXuzLMpfIlYIwPPaSS/CF0=; b=eyg1QzF03rqhyydDCQcEKEqa7WpGNIYRvUkOnPKQKTc6VH/9cwy5rSb8GA1N39ISBibVUaTWUS8qvO2Tktmeo9MCJv5rzX/XEzRGgNkJwq/edMoK3kpqwzvvYzNCrVwBCARvaFtP/zDltGidKskLjzP7SFhJ8I8hIvH0/kKadcYUzwpc8E6CWgSGjk60mjl+PqEUULq/T+yNw1DEVis3cYOr4uRN3RUddnKMh5MuqW+n6+uz3xLkzAgFVXHCts8+3F5BRvwNuFjQJzsT2LAXEOETftiVJ2wC/qtzq4Zku1fw1B7Q0BPAaiTPDLKKCw2XwvqINcevF5dPX00lm64NkQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ur7LYKesMy8ZoqMQAUXZuUXuzLMpfIlYIwPPaSS/CF0=; b=yZvHjuAFcgM3nKnJi8YEPiKpuQqzm6437ZL9SFYq06xhuAmDpCZ5mVW2foAVfySVJgdJJw3j/QLNNzK+OHBpE7n3k3/u2ICS7i8tbvhQXNE5FTDB2YrAGe14eZnn6cCmeNhg1X6TMgttotK+3sdHJ9F12dVDx5KMLi3MmL7VzP8= Received: from CY4PR1101MB2118.namprd11.prod.outlook.com (2603:10b6:910:1f::10) by CY4PR11MB1512.namprd11.prod.outlook.com (2603:10b6:910:a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.26; Mon, 29 Jun 2020 18:07:29 +0000 Received: from CY4PR1101MB2118.namprd11.prod.outlook.com ([fe80::410b:7807:181:1620]) by CY4PR1101MB2118.namprd11.prod.outlook.com ([fe80::410b:7807:181:1620%4]) with mapi id 15.20.3131.027; Mon, 29 Jun 2020 18:07:29 +0000 From: "Carrillo, Erik G" To: Phil Yang , "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: AQHWQKuLMcN95WYLzky6aL2QD3WEIajkeeaAgAItOBCAB7wVAIABm54w Date: Mon, 29 Jun 2020 18:07:29 +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: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.55.52.215] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9b7408fa-9983-45d5-a34e-08d81c57496a x-ms-traffictypediagnostic: CY4PR11MB1512: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 044968D9E1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5H9FqFHPLOzu7zYlbTtueLre/3cDnGUihAD9F5cNkFrX70TZY238GpDtfnMCIchwLRUU3KnGSFCMaSfrKw2sKMqgoWBIa5be+zQN9+b3EdgXSURWP//BFqzGa79WMzcgS4OiAW0pexwVr7IyEhkax9yVm+YPsmNXgQPj+uCDqReF755Fd11GQYkhEexykKjxSas/5CROwVs7wf8j2uEd0einbsMhQkhHwU7RjqBYUsSRavS0afXPfUaIzZ8IqRng2ofBbLDQxcZVqRSkHm73fPMAfVSyh2JB0iwpuxzw6I6gOuYH4Cy0AOdJu8MIdpRro7J/Eg71kYmbJzBhVOuGwA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR1101MB2118.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(346002)(396003)(366004)(136003)(7696005)(26005)(2906002)(30864003)(8676002)(66946007)(5660300002)(71200400001)(76116006)(66446008)(52536014)(186003)(53546011)(6506007)(33656002)(66556008)(64756008)(66476007)(8936002)(83380400001)(9686003)(54906003)(110136005)(478600001)(316002)(55016002)(4326008)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: OvlD2CdEZRIqyLQyMxXM5z6zDQuxhbqs958UnflcXRuCu2Ys2UZqUaq0U0sfnA2HQKC3Exp/3SWO2rS+xZQj+nys6jU2cmoevTXCq9qP9Hn9KBOir6nWI+76v7GYu/U5Q05XCjAVtvjVgyUbwoHmrLpQyntZkpAahYTX8QtQCIRX/n3ngvXzMYqjN02FMXhYrAwcc7EHsxxOEPnPMKrbvOU6TFxMj05pd9wElOLr1FfsRQ3UggQOWmAEnaLSk3U5gcRgYfSywR7iVq8aVXaZmHtgyMlCcuhWaDlb9uF7Rp7gUPiAAyzW91lMYrkSzKnpgXCPeza0JP+MQNdPEFQhcbcNPPfOwPVZC0Ip2LZZ3bNfQOthmc31C44yPjEUlWtnpRqUn0vD2nnSYe0gBlkOzk6PVKJmMfQUgFWZxXcg40KkcWYoZGZunzIXx+v8MJBUrN2YY1Qbr4g14xXvR7OJw/cbejDcSdM8vUMV5SI5974= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY4PR1101MB2118.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9b7408fa-9983-45d5-a34e-08d81c57496a X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2020 18:07:29.1495 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yN24vht3cgkm9/QF6OHxdAf+7Xg1m+HK1mhk+4ZWQYF0UWJfABBGVty0t6iDsjD5EA4whKYAASfHH+mwH/yhhrkaftnpJ82cr+xDj+pRnus= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1512 X-OriginatorOrg: intel.com 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" > -----Original Message----- > From: Phil Yang > Sent: Sunday, June 28, 2020 12:34 PM > To: Carrillo, Erik G ; 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 Erick, >=20 > > -----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 > > > > Hi Phil, > > > > Comment in-line: > > > > > -----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 c11 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_burst 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 > > > unknow after swtim_cancel_burst. > > > So it should be safe to remove them if no other thread access them > > > after 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 > > > > > > > In this case, I see the fence as (more importantly) ensuring the state > update > > is visible to other threads... do I misunderstand? I suppose we could= also > > update the state with an __atomic_store(..., __ATOMIC_RELEASE), but > > perhaps that roughly equivalent? >=20 > Yeah. In my understanding, the fence ensures the state and the > implementation-specific opaque data update are visible between other > timer arm and cancel threads. > Actually, we only care about the state's value here. > The atomic RELEASE can also make sure all writes in the current thread ar= e > visible in other threads that acquire the same atomic variable. > So I think we can remove the fence and update the state with RELEASE then > load the state with ACQUIRE in the timer arm and the cancel threads to > achieve the same goal. Ok, that sounds good to me. Thanks, Erik >=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