Hi Luca,
Appreciate your comments.
>
> liburcu has many flavours already, qsbr being one of them. If none of those
> are optimal for this use case, why not work with upstream to either improve
> the existing flavours, or add a new one?
>
> You have the specific knowledge and expertise about the requirements
> needs for the implementation for this use case, and they have the long-
> time and extensive experience maintaining the library on a wide range of
> systems and use cases. Why not combine both?
> I might be wrong, but to me, nothing described above seems to be
> particularly or uniquely tied to implementing a software dataplane or to
> DPDK.
This comment does not help much, I would prefer a more concrete comment. If
possible, can you please mention where else these features are required? IMO,
if these were required for other use cases, they would have been present in
liburcu already.
IMHO we should pool and share wherever possible, rather than build
> an ecosystem closed onto itself.
>
> Just my 2c of course!
I would say this is true for some of the other libraries in DPDK as well [1] or
in fact for the whole of DPDK. Linux Kernel has introduced XDP. I would say
Linux Kernel has much vibrant history and community. If XDP lacks some of the
features we want, why not work with Linux community to improve it and not do
DPDK?
[1] https://github.com/urcu/userspace-rcu/blob/master/doc/uatomic-api.md
IMO, we should focus our discussion on how relevant rte_tqs is to DPDK, whether
it solves the problems people face while using DPDK and the value add it
brings. This should be the basis for the acceptance rather than what is
available elsewhere.
>
> > > 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?
> >
> > I have not had any discussions on this. Customers are mainly focused
> > on having a solution on which they have meaningful control. They want
> > to be able to submit a patch and change things if required. For ex:
> > barriers for Arm [7] are not optimal. How easy is it to change this
> > and get it into distros (there are both internal and external factors
> > here)?
>
> It's just as easy (or as hard) as it is with DPDK. So it's either wait for the
> distros to update, or rebuild locally.
>
I have not worked with that community, hence I cannot comment on that.
Apologies for asking some hard questions, but, do you know how easy it is to
change the license for liburcu? Can the DPDK governing board take a decision to
change the license for liburcu?
> --
> Kind regards,
> Luca Boccassi
