Hi Yipeng,
I agree with you on RCU. It solves only part of the problem and
requires application involvement. Use of atomics is required to solve few more
problems.
Not solving the preemptible writer issue will change the behavior for existing
applications, is that ok?
I will submit a RFC with my ideas.
Thank you,
Honnappa
-----Original Message-----
From: Wang, Yipeng1 <yipeng1.w...@intel.com>
Sent: Wednesday, July 11, 2018 8:31 PM
To: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com>; De Lara Guarch, Pablo
<pablo.de.lara.gua...@intel.com>
Cc: dev@dpdk.org; Richardson, Bruce <bruce.richard...@intel.com>;
vgu...@caviumnetworks.com; brijesh.s.si...@gmail.com; nd <n...@arm.com>; Tai,
Charlie <charlie....@intel.com>; Wang, Ren <ren.w...@intel.com>; Gobriel, Sameh
<sameh.gobr...@intel.com>
Subject: RE: [PATCH v4 0/8] Add read-write concurrency to rte_hash library
Hi, Honnappa,
Thanks for the comment.
RCU can handle one of the currency issue (key deletion while lookup) that has
been discussed before, but we think it is not easy for RCU-alone to protect
reader from cuckoo path displacement. Also, RCU solution requires user
interaction.
We agree that the current rwlock does not support preemptable writer. But a
more advanced rwlock with priority could be implemented in the future into the
rwlock library.
Thanks
Yipeng
>-----Original Message-----
>From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com]
>Sent: Tuesday, July 10, 2018 11:00 AM
>To: Wang, Yipeng1 <yipeng1.w...@intel.com>; De Lara Guarch, Pablo
><pablo.de.lara.gua...@intel.com>
>Cc: dev@dpdk.org; Richardson, Bruce <bruce.richard...@intel.com>;
>vgu...@caviumnetworks.com; brijesh.s.si...@gmail.com; nd <n...@arm.com>
>Subject: RE: [PATCH v4 0/8] Add read-write concurrency to rte_hash
>library
>
>Hi Yipeng/Pablo,
> Apologies for my delayed comments
>
>-----Original Message-----
>From: Yipeng Wang <yipeng1.w...@intel.com>
>Sent: Monday, July 9, 2018 5:45 AM
>To: pablo.de.lara.gua...@intel.com
>Cc: dev@dpdk.org; yipeng1.w...@intel.com; bruce.richard...@intel.com;
>Honnappa Nagarahalli <honnappa.nagaraha...@arm.com>;
>vgu...@caviumnetworks.com; brijesh.s.si...@gmail.com
>Subject: [PATCH v4 0/8] Add read-write concurrency to rte_hash library
>
>This patch set adds the read-write concurrency support in rte_hash.
>A new flag value is added to indicate if read-write concurrency is
>needed during creation time. Test cases are implemented to do functional and
>performance tests.
>
>The new concurrency model is based on rte_rwlock. When Intel TSX is
>available and the users indicate to use it, the TM version of the
>rte_rwlock will be called. Both multi-writer and read-write concurrency are
>protected by the rte_rwlock instead of the x86 specific RTM instructions, so
>the x86 specific header rte_cuckoo_hash_x86.h is removed and the code is
>infused into the main .c file.
>
>IMO, at a high-level, there are two use cases for the rte_hash library:
>1) Writers are on control plane and data plane are readers
>2) Writers and readers are on data plane
>
>This distinction is required as in the case of 1) writers are
>pre-emptible. If I consider platforms without TSX (I do not know how
>Intel TSX works), the rte_rwlock implementation is blocking. A writer
>on the control plane can take the lock and get pre-empted. Since rte_rwlock is
>used for read-write concurrency, it will block the readers (on the data plane)
>for an extended duration. I think, support for RCU is required to solve this
>issue.
>
>
