> > > > > >> Hi Stephen, > > >> > > >> No, we don’t support RCU. Wouldn’t rw-locks be enough to support your > usecases? > > >> > > >> Florin > > >> > > >>> On Oct 29, 2018, at 12:40 PM, Stephen Hemminger > <step...@networkplumber.org> wrote: > > >>> > > >>> Is it possible to do Read Copy Update with VPP? Either using > > >>> Userspace RCU (https://librcu.org) or manually. RCU is very > > >>> efficient way to handle read mostly tables and other dynamic cases such > as plugins. > > >>> > > >>> The several things that are needed are non-preempt, atomic update > > >>> of a pointer and a mechanism to be sure all active threads have > > >>> gone through a quiescent period. I don't think VPP will preempt > > >>> one node for another so that is done. The atomic update is > > >>> relatively easy with basic barriers, either from FD.IO, DPDK, or native > compiler operations. But is there an API to have a quiescent period marker in > the main VPP vector scheduler? > > >>> > > >>> Something like the QSBR model of Userspace RCU library. > > >>> (each thread calls rcu_queiscent_state() periodically) would be > > >>> ideal. > > >>> > > >>> -=-=-=-=-=-=-=-=-=-=-=- > > >>> Links: You receive all messages sent to this group. > > >>> > > >>> View/Reply Online (#11023): > > >>> https://lists.fd.io/g/vpp-dev/message/11023 > > >>> Mute This Topic: https://lists.fd.io/mt/27785182/675152 > > >>> Group Owner: vpp-dev+ow...@lists.fd.io > > >>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub > [fcoras.li...@gmail.com] > > >>> -=-=-=-=-=-=-=-=-=-=-=- > > >> > > > > > > No reader-writer locks are 100's of times slower. In fact reader > > > write locks are slower than normal spin lock. > > > > > > > I guess you meant that in general, and I can see how for scenarios with > multiple writers and readers performance can be bad. But from your original > message I assumed you’re mostly interested in concurrent read performance > with few writes. For such scenarios I would expect our current, simple, spin > and rw lock implementations to not be that bad. If that’s provably not the > case, > we should definitely consider doing RCU. > > > > Also worth noting that a common pattern in vpp is to have per thread data > structures and then entirely avoid locking. For lookups we typically use the > bihash and that is thread safe. When you say 'per thread data structures', does it mean the data structures will be duplicated for each data plane thread?
> > > > Florin > > > > > > https://www.researchgate.net/publication/247337469_RCU_vs_Locking_Perf > ormance_on_Different_CPUs > > https://lwn.net/Articles/263130/
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11045): https://lists.fd.io/g/vpp-dev/message/11045 Mute This Topic: https://lists.fd.io/mt/27785182/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
