Hi, I guess your proposal is to let the user application to handle all the concurrency using RCU and locks. That could be complementary and orthogonal to our current implementation. User could choose to do this way if TSX is not available, and if they want more control over the concurrency implementations. A new flag value could be added to allow this mode.
Please copy us when sending out the RFC, we will be happy to review it. >-----Original Message----- >From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com] >Sent: Wednesday, July 11, 2018 7:36 PM >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>; 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 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. >> >>
