On Mon, 29 Oct 2018 14:58:07 -0700 Florin Coras <fcoras.li...@gmail.com> wrote:
> > On Oct 29, 2018, at 1:42 PM, Stephen Hemminger <step...@networkplumber.org> > > wrote: > > > > On Mon, 29 Oct 2018 13:20:27 -0700 > > Florin Coras <fcoras.li...@gmail.com> wrote: > > > >> 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. > > Florin > > https://www.researchgate.net/publication/247337469_RCU_vs_Locking_Performance_on_Different_CPUs https://lwn.net/Articles/263130/
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11038): https://lists.fd.io/g/vpp-dev/message/11038 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] -=-=-=-=-=-=-=-=-=-=-=-
