> On Oct 30, 2018, at 9:02 PM, Honnappa Nagarahalli > <honnappa.nagaraha...@arm.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. > When you say 'per thread data structures', does it mean the data structures > will be duplicated for each data plane thread?
No, we don’t duplicate the data. Instead, we rely on RSS hashing to pin flows to workers and then build per worker state. For scenarios when that doesn’t work, we handoff flows between workers. Florin > >>> >>> Florin >>> >>> >> >> https://www.researchgate.net/publication/247337469_RCU_vs_Locking_Perf >> <https://www.researchgate.net/publication/247337469_RCU_vs_Locking_Perf> >> ormance_on_Different_CPUs >> >> https://lwn.net/Articles/263130/ <https://lwn.net/Articles/263130/>
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11047): https://lists.fd.io/g/vpp-dev/message/11047 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] -=-=-=-=-=-=-=-=-=-=-=-
