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

[Stephen Hemminger <stephen@networkplumber.org>]

On Wed, 28 Nov 2018 05:31:56 +0000
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:

> > > 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 :)
> 
> > 

Reinventing RCU is not helping anyone.


DPDK needs to fix its dependency model, and just admit that it is ok
to build off of more than glibc.

Having used liburcu, it can be done in a small manner and really isn't that
confusing. 

Is your real issue the LGPL license of liburcu for your skittish customers?