[dpdk-dev] [RFC 0/3] tqs: add thread quiescent state library

[Honnappa Nagarahalli]

> >
> > On Wed, 21 Nov 2018 21:30:52 -0600
> > Honnappa Nagarahalli <honnappa.nagarahalli at 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.