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