Re: rte_hash thread safe

[Brijesh Singh <brijesh.s.singh@gmail.com>]

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
<stephen@networkplumber.org> wrote:
> On Mon, 23 Apr 2018 17:48:50 -0700
> Jim Murphy <jmurphy@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.