Another idea would be to keep the synchronization at the thread level and let the application handle RCU. This will keep the cost down if the application has multiple tables requiring RCU. It will also allow the application to use its own methods to declare end of quiescent period.
However, the rte_hash library has to support this. There needs to be a distinction between deleting an entry and freeing the memory (or returning the entry to the free pool) associated with the entry. Freeing of the memory needs to happen after the quiescent period. -----Original Message----- From: dev <dev-boun...@dpdk.org> On Behalf Of Jim Murphy Sent: Monday, April 23, 2018 9:13 PM To: Stephen Hemminger <step...@networkplumber.org> Cc: Brijesh Singh <brijesh.s.si...@gmail.com>; dev@dpdk.org Subject: Re: [dpdk-dev] rte_hash thread safe Right, the threads using the DPDK libraries must do the right RCU stuff, declare quiescent, etc. I mentioned hooks to address the licensing issue. So for places in rte_hash were synchronization must be done a no-op function could be called but users could replace that function with one of their choosing. Thanks, Jim 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. >
