Thank you all for explaining. My updates are uncommon; Adding concept of quiescent threads should be worst case loss of 1 full burst cpu cycles on the threads. This should be acceptable infrequent delay in packet processing.
I need data on performance of librcu lookups under infrequent updates, if the difference is not significant on x86, I will use librcu. On Mon, Apr 23, 2018 at 6:14 PM, Stephen Hemminger <step...@networkplumber.org> wrote: > On Mon, 23 Apr 2018 17:48:50 -0700 > Jim Murphy <jmur...@arista.com> wrote: > >> Anecdotally I've heard that the urcu hash implementation is slower than >> rte_hash based on pure lookup performance. Has anyone considered adding RCU >> hooks into rte_hash? > > > Not really possible with DPDK (as I said earlier) because DPDK does not have > concept > of thread quiescent period to allow for safe deletion. You could manually > use RCU > concepts of RCU and RTE hash; it would require using userspace RCU primitives > inside DPDK. This would cause a dependency that would prevent that from ever > being merged upstream due to license conflict; but since DPDK is liberal BSD > license you are free to do it and maintain it on your own.