You can look at hash table support under librte_table, we are using it for tcp stateful and syncache table (16 bytes key), supports optimized burst look ups, pretty good performance at line rate with up to half a billion entries in syn cache lru table and 33 million in flows ext table. However these tables are pre-allocated and not thread safe (tradeoff with performance), we use per core tables if running multicore .... *I thank all creators/contributors involved, it definitely been huge help in my project *
On Tue, Apr 24, 2018 at 8:34 PM, Brijesh Singh <brijesh.s.si...@gmail.com> wrote: > 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. >
