> > > > 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. > > Agree with the dependency issues. Sometimes flexibility also causes confusion and features that are not necessarily required for a targeted use case. I have seen that much of the functionality that can be left to the application is implemented as part of the library. I think having it in DPDK will give us control over the amount of capability this library will have and freedom over changes we would like to make to such a library. I also view DPDK as one package where all things required for data plane development are available.
> > For RCU, the big issue for me is the testing and documentation of how > > to do RCU safely. Many people get it wrong! Hopefully, we all will do a better job collectively :) > > > 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.
