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

[Honnappa Nagarahalli]

> > >
> >
> > 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.
The licensing info [1] is very interesting. Again I am no lawyer :)

[1] https://github.com/urcu/userspace-rcu/blob/master/include/urcu/static/urcu-qsbr.h#L184