From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 41F991B441 for ; Tue, 27 Nov 2018 23:49:25 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Nov 2018 14:49:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,288,1539673200"; d="scan'208";a="104140182" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by orsmga003.jf.intel.com with ESMTP; 27 Nov 2018 14:49:22 -0800 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.13]) by irsmsx105.ger.corp.intel.com ([169.254.7.144]) with mapi id 14.03.0415.000; Tue, 27 Nov 2018 22:49:21 +0000 From: "Van Haaren, Harry" To: Stephen Hemminger , Honnappa Nagarahalli CC: "dev@dpdk.org" , "nd@arm.com" , "dharmik.thakkar@arm.com" , "malvika.gupta@arm.com" , "gavin.hu@arm.com" Thread-Topic: [dpdk-dev] [RFC 0/3] tqs: add thread quiescent state library Thread-Index: AQHUghPtP0Ni2Bpj10OyDEpWYkpaFaVkPMOAgAADBtA= Date: Tue, 27 Nov 2018 22:49:21 +0000 Message-ID: References: <20181122033055.3431-1-honnappa.nagarahalli@arm.com> <20181127142803.423c9b00@xeon-e3> In-Reply-To: <20181127142803.423c9b00@xeon-e3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTczMzUxZDctMzJhNS00NzY5LThhMmUtYzlkMzhhYzk4N2IxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoid0xkUEtFTE1BXC8rbTdJOEcybmF0M1dQWVFDM21kUVN6U09VXC9qdVVzM3BGajNwVDFCRXNpTXB4a1wvQ0tZMG5JVyJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC 0/3] tqs: add thread quiescent state library 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: Tue, 27 Nov 2018 22:49:25 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger > Sent: Tuesday, November 27, 2018 2:28 PM > To: Honnappa Nagarahalli > Cc: dev@dpdk.org; nd@arm.com; dharmik.thakkar@arm.com; malvika.gupta@arm.= com; > gavin.hu@arm.com > Subject: Re: [dpdk-dev] [RFC 0/3] tqs: add thread quiescent state library >=20 > On Wed, 21 Nov 2018 21:30:52 -0600 > Honnappa Nagarahalli wrote: >=20 > > Lock-less data structures provide scalability and determinism. > > They enable use cases where locking may not be allowed > > (for ex: real-time applications). > > > > Dharmik Thakkar (1): > > test/tqs: Add API and functional tests > > > > Honnappa Nagarahalli (2): > > log: add TQS log type > > tqs: add thread quiescent state library > > > > config/common_base | 6 + > > lib/Makefile | 2 + > > lib/librte_eal/common/include/rte_log.h | 1 + > > lib/librte_tqs/Makefile | 23 + > > lib/librte_tqs/meson.build | 5 + > > lib/librte_tqs/rte_tqs.c | 249 +++++++++++ > > lib/librte_tqs/rte_tqs.h | 352 +++++++++++++++ > > lib/librte_tqs/rte_tqs_version.map | 16 + > > lib/meson.build | 2 +- > > mk/rte.app.mk | 1 + > > test/test/Makefile | 2 + > > test/test/autotest_data.py | 6 + > > test/test/meson.build | 5 +- > > test/test/test_tqs.c | 540 ++++++++++++++++++++++++ > > 14 files changed, 1208 insertions(+), 2 deletions(-) > > create mode 100644 lib/librte_tqs/Makefile > > create mode 100644 lib/librte_tqs/meson.build > > create mode 100644 lib/librte_tqs/rte_tqs.c > > create mode 100644 lib/librte_tqs/rte_tqs.h > > create mode 100644 lib/librte_tqs/rte_tqs_version.map > > create mode 100644 test/test/test_tqs.c > > >=20 > Mixed feelings about this one. >=20 > Love to see RCU used for more things since it is much better than > reader/writer > locks for many applications. But hate to see DPDK reinventing every other > library > and not reusing code. Userspace RCU https://liburcu.org/ is widely suppor= ted > by > distro's, more throughly tested and documented, and more flexiple. >=20 > The issue with many of these reinventions is a tradeoff of DPDK growing > another dependency on external library versus using common code. >=20 > For RCU, the big issue for me is the testing and documentation of how to = do > RCU > safely. Many people get it wrong! Some notes on liburcu (and my amateur understanding of LGPL, I'm not a lice= nse lawyer :) Liburcu is LGPL, which AFAIK means we must dynamically link applications if= the application code is BSD or other permissive licenses. The side effect of this is that urcu function calls must be "real" function= calls and inlining them is not possible. Therefore using liburcu in LGPL m= ode could have a performance impact in this case. I expect estimating the p= erformance cost would be difficult as its pretty much a case-by-case depending on what you're doing = in the surrounding code. Generally I'm in favour of using established libraries (particularly for co= mplex functionality like RCU) but in this case I think there's a tradeoff w= ith raw performance.