From mboxrd@z Thu Jan 1 00:00:00 1970 From: Honnappa Nagarahalli Subject: Re: [PATCH v4 0/8] Add read-write concurrency to rte_hash library Date: Thu, 12 Jul 2018 02:36:22 +0000 Message-ID: References: <1528455078-328182-1-git-send-email-yipeng1.wang@intel.com> <1531133103-437316-1-git-send-email-yipeng1.wang@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , "Richardson, Bruce" , "vguvva@caviumnetworks.com" , "brijesh.s.singh@gmail.com" , nd , "Tai, Charlie" , "Wang, Ren" , "Gobriel, Sameh" To: "Wang, Yipeng1" , "De Lara Guarch, Pablo" Return-path: Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20045.outbound.protection.outlook.com [40.107.2.45]) by dpdk.org (Postfix) with ESMTP id CA7831B579 for ; Thu, 12 Jul 2018 04:36:25 +0200 (CEST) In-Reply-To: Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Yipeng, I agree with you on RCU. It solves only part of the problem and requires a= pplication involvement. Use of atomics is required to solve few more proble= ms. Not solving the preemptible writer issue will change the behavior for exist= ing applications, is that ok? I will submit a RFC with my ideas. Thank you, Honnappa -----Original Message----- From: Wang, Yipeng1 =20 Sent: Wednesday, July 11, 2018 8:31 PM To: Honnappa Nagarahalli ; De Lara Guarch, Pa= blo Cc: dev@dpdk.org; Richardson, Bruce ; vguvva@ca= viumnetworks.com; brijesh.s.singh@gmail.com; nd ; Tai, Charlie = ; Wang, Ren ; Gobriel, Sameh 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 h= as been discussed before, but we think it is not easy for RCU-alone to prot= ect 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.Nagarahalli@arm.com] >Sent: Tuesday, July 10, 2018 11:00 AM >To: Wang, Yipeng1 ; De Lara Guarch, Pablo=20 > >Cc: dev@dpdk.org; Richardson, Bruce ;=20 >vguvva@caviumnetworks.com; brijesh.s.singh@gmail.com; nd >Subject: RE: [PATCH v4 0/8] Add read-write concurrency to rte_hash=20 >library > >Hi Yipeng/Pablo, > Apologies for my delayed comments > >-----Original Message----- >From: Yipeng Wang >Sent: Monday, July 9, 2018 5:45 AM >To: pablo.de.lara.guarch@intel.com >Cc: dev@dpdk.org; yipeng1.wang@intel.com; bruce.richardson@intel.com;=20 >Honnappa Nagarahalli ;=20 >vguvva@caviumnetworks.com; brijesh.s.singh@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=20 >needed during creation time. Test cases are implemented to do functional a= nd performance tests. > >The new concurrency model is based on rte_rwlock. When Intel TSX is=20 >available and the users indicate to use it, the TM version of the=20 >rte_rwlock will be called. Both multi-writer and read-write concurrency ar= e 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 i= s 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=20 >pre-emptible. If I consider platforms without TSX (I do not know how=20 >Intel TSX works), the rte_rwlock implementation is blocking. A writer=20 >on the control plane can take the lock and get pre-empted. Since rte_rwloc= k is used for read-write concurrency, it will block the readers (on the dat= a plane) for an extended duration. I think, support for RCU is required to = solve this issue. > >