From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 5C4A71B065 for ; Fri, 13 Jul 2018 03:47:37 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jul 2018 18:47:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,346,1526367600"; d="scan'208";a="56506308" Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by orsmga008.jf.intel.com with ESMTP; 12 Jul 2018 18:47:33 -0700 Received: from orsmsx105.amr.corp.intel.com ([169.254.2.59]) by ORSMSX102.amr.corp.intel.com ([169.254.3.209]) with mapi id 14.03.0319.002; Thu, 12 Jul 2018 18:47:32 -0700 From: "Wang, Yipeng1" To: Honnappa Nagarahalli , "De Lara Guarch, Pablo" CC: "dev@dpdk.org" , "Richardson, Bruce" , "vguvva@caviumnetworks.com" , "brijesh.s.singh@gmail.com" , nd , "Tai, Charlie" , "Wang, Ren" , "Gobriel, Sameh" Thread-Topic: [PATCH v4 0/8] Add read-write concurrency to rte_hash library Thread-Index: AQHUF62Y3wOysChRCUuSHkQimeoNYaSItMYAgAIZihCAAInrAIABDsMQ Date: Fri, 13 Jul 2018 01:47:32 +0000 Message-ID: References: <1528455078-328182-1-git-send-email-yipeng1.wang@intel.com> <1531133103-437316-1-git-send-email-yipeng1.wang@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzNmMDNhNmYtMmY5NS00NmVlLWFjNmMtODk1NDE4YjE2YmRjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiWEp6aWhQZlJBdExoT2RVUkh4WE9OUUlDXC9QVWpLZTRYd21Fd1czXC9pUFhvOHR0NmJtWUdhYzBaTFNCejlCN0N4In0= x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v4 0/8] Add read-write concurrency to rte_hash library X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 01:47:39 -0000 Hi,=20 I guess your proposal is to let the user application to handle all the conc= urrency 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.Nagarahalli@arm.com] >Sent: Wednesday, July 11, 2018 7:36 PM >To: Wang, Yipeng1 ; De Lara Guarch, Pablo >Cc: dev@dpdk.org; Richardson, Bruce ; vguvva@c= aviumnetworks.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 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 exis= ting applications, is that ok? > >I will submit a RFC with my ideas. > >Thank you, >Honnappa > >-----Original Message----- >From: Wang, Yipeng1 >Sent: Wednesday, July 11, 2018 8:31 PM >To: Honnappa Nagarahalli ; De Lara Guarch, P= ablo >Cc: dev@dpdk.org; Richardson, Bruce ; vguvva@c= aviumnetworks.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 = has been discussed before, but we think it is not easy for >RCU-alone to protect reader from cuckoo path displacement. Also, RCU solut= ion 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 >> >>Cc: dev@dpdk.org; Richardson, Bruce ; >>vguvva@caviumnetworks.com; brijesh.s.singh@gmail.com; nd >>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 >>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; >>Honnappa Nagarahalli ; >>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 >>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 a= re protected by the rte_rwlock instead of the x86 specific >RTM instructions, so the x86 specific header rte_cuckoo_hash_x86.h is remo= ved 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_rwlo= ck 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. >> >>