> -----Original Message----- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen Hemminger > Sent: Tuesday, November 27, 2018 2:28 PM > To: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com> > Cc: dev@dpdk.org; n...@arm.com; dharmik.thak...@arm.com; > malvika.gu...@arm.com; > gavin...@arm.com > Subject: Re: [dpdk-dev] [RFC 0/3] tqs: add thread quiescent state library > > On Wed, 21 Nov 2018 21:30:52 -0600 > Honnappa Nagarahalli <honnappa.nagaraha...@arm.com> wrote: > > > Lock-less data structures provide scalability and determinism. > > They enable use cases where locking may not be allowed > > (for ex: real-time applications). > >
<snip detailed RFC commit messag> > > 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 > > > > Mixed feelings about this one. > > 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 supported > by > distro's, more throughly tested and documented, and more flexiple. > > The issue with many of these reinventions is a tradeoff of DPDK growing > another dependency on external library versus using common code. > > 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 license 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 mode could have a performance impact in this case. I expect estimating the performance 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 complex functionality like RCU) but in this case I think there's a tradeoff with raw performance.
