From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 568A3F11 for ; Wed, 16 Jan 2019 16:56:53 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2019 07:56:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,486,1539673200"; d="scan'208";a="135157587" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by fmsmga002.fm.intel.com with ESMTP; 16 Jan 2019 07:56:50 -0800 Received: from irsmsx111.ger.corp.intel.com (10.108.20.4) by IRSMSX153.ger.corp.intel.com (163.33.192.75) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 16 Jan 2019 15:56:49 +0000 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.116]) by irsmsx111.ger.corp.intel.com ([169.254.2.160]) with mapi id 14.03.0415.000; Wed, 16 Jan 2019 15:56:49 +0000 From: "Ananyev, Konstantin" To: Honnappa Nagarahalli , "dev@dpdk.org" , "stephen@networkplumber.org" , "paulmck@linux.ibm.com" CC: "Gavin Hu (Arm Technology China)" , Dharmik Thakkar , nd , nd Thread-Topic: [RFC v2 1/2] rcu: add RCU library supporting QSBR mechanism Thread-Index: AQHUmZwkA3lN9JDuXEiclvOGJBGOtKWwUixggACXpdCAAUkpAA== Date: Wed, 16 Jan 2019 15:56:49 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258010D904AC7@irsmsx105.ger.corp.intel.com> References: <20181122033055.3431-1-honnappa.nagarahalli@arm.com> <20181222021420.5114-1-honnappa.nagarahalli@arm.com> <20181222021420.5114-2-honnappa.nagarahalli@arm.com> <2601191342CEEE43887BDE71AB977258010D904212@irsmsx105.ger.corp.intel.com> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMmJkOTkzYjMtNDY5Zi00YjA1LWI5OTQtYjM3ZGE2OGQ2MzFjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiaVdnb3hCMDN6S1ZBdGZucW5PckVlUFlPa3VCZWVjSDhiNGJQRkNkbHVpa20yXC83YVZjYVwvN3dReEo3WTJyaHRaIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC v2 1/2] rcu: add RCU library supporting QSBR mechanism 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: Wed, 16 Jan 2019 15:56:53 -0000 > > ... > > > > > diff --git a/lib/librte_rcu/rte_rcu_qsbr.h > > > b/lib/librte_rcu/rte_rcu_qsbr.h new file mode 100644 index > > > 000000000..c818e77fd > > > --- /dev/null > > > +++ b/lib/librte_rcu/rte_rcu_qsbr.h > > > @@ -0,0 +1,321 @@ > > > +/* SPDX-License-Identifier: BSD-3-Clause > > > + * Copyright (c) 2018 Arm Limited > > > + */ > > > + > > > +#ifndef _RTE_RCU_QSBR_H_ > > > +#define _RTE_RCU_QSBR_H_ > > > + > > > +/** > > > + * @file > > > + * RTE Quiescent State Based Reclamation (QSBR) > > > + * > > > + * Quiescent State (QS) is any point in the thread execution > > > + * where the thread does not hold a reference to shared memory. > > > + * A critical section for a data structure can be a quiescent state > > > +for > > > + * another data structure. > > > + * > > > + * This library provides the ability to identify quiescent state. > > > + */ > > > + > > > +#ifdef __cplusplus > > > +extern "C" { > > > +#endif > > > + > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > + > > > +/**< Maximum number of reader threads supported. */ #define > > > +RTE_RCU_MAX_THREADS 128 > > > + > > > +#if !RTE_IS_POWER_OF_2(RTE_RCU_MAX_THREADS) > > > +#error RTE_RCU_MAX_THREADS must be a power of 2 #endif > > > + > > > +/**< Number of array elements required for the bit-map */ #define > > > +RTE_QSBR_BIT_MAP_ELEMS (RTE_RCU_MAX_THREADS/(sizeof(uint64_t) > > * 8)) > > > + > > > +/* Thread IDs are stored as a bitmap of 64b element array. Given > > > +thread id > > > + * needs to be converted to index into the array and the id within > > > + * the array element. > > > + */ > > > +#define RTE_QSBR_THR_INDEX_SHIFT 6 > > > +#define RTE_QSBR_THR_ID_MASK 0x3f > > > + > > > +/* Worker thread counter */ > > > +struct rte_rcu_qsbr_cnt { > > > + uint64_t cnt; /**< Quiescent state counter. */ } > > > +__rte_cache_aligned; > > > + > > > +/** > > > + * RTE thread Quiescent State structure. > > > + */ > > > +struct rte_rcu_qsbr { > > > + uint64_t reg_thread_id[RTE_QSBR_BIT_MAP_ELEMS] > > __rte_cache_aligned; > > > + /**< Registered reader thread IDs - reader threads reporting > > > + * on this QS variable represented in a bit map. > > > + */ > > > + > > > + uint64_t token __rte_cache_aligned; > > > + /**< Counter to allow for multiple simultaneous QS queries */ > > > + > > > + struct rte_rcu_qsbr_cnt w[RTE_RCU_MAX_THREADS] > > __rte_cache_aligned; > > > + /**< QS counter for each reader thread, counts upto > > > + * current value of token. > > > > As I understand you decided to stick with neutral thread_id and let use= r > > define what exactly thread_id is (lcore, syste, thread id, something el= se)? > Yes, that is correct. I will reply to the other thread to continue the di= scussion. >=20 > > If so, can you probably get rid of RTE_RCU_MAX_THREADS limitation? > I am not seeing this as a limitation. The user can change this if require= d. May be I should change it as follows: > #ifndef RTE_RCU_MAX_THREADS > #define RTE_RCU_MAX_THREADS 128 > #endif Yep, that's better, though it would still require user to rebuild the code if he would like to increase total number of threads supported. Though it seems relatively simply to extend current code to support dynamic max thread num here (2 variable arrays plus shift value plus mask).= =20 >=20 > > I.E. struct rte_rcu_qsbr_cnt w[] and allow user at init time to define = max > > number of threads allowed. > > Or something like: > > #define RTE_RCU_QSBR_DEF(name, max_thread) struct name { \ > > uint64_t reg_thread_id[ALIGN_CEIL(max_thread, 64) >> 6]; \ > > ... > > struct rte_rcu_qsbr_cnt w[max_thread]; \ } > I am trying to understand this. I am not following why 'name' is required= ? Would the user call 'RTE_RCU_QSBR_DEF' in the application > header file? My thought here was to allow user to define his own structures, depending on the number of max threads he needs/wants: RTE_RCU_QSBR_DEF(rte_rcu_qsbr_128, 128); RTE_RCU_QSBR_DEF(rte_rcu_qsbr_64, 64); ... Konstantin