From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 99EBF1B173 for ; Fri, 13 Jul 2018 03:55:23 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jul 2018 18:55:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,346,1526367600"; d="scan'208";a="64342860" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by FMSMGA003.fm.intel.com with ESMTP; 12 Jul 2018 18:55:21 -0700 Received: from orsmsx105.amr.corp.intel.com ([169.254.2.59]) by ORSMSX103.amr.corp.intel.com ([169.254.5.19]) with mapi id 14.03.0319.002; Thu, 12 Jul 2018 18:55:21 -0700 From: "Wang, Yipeng1" To: Thomas Monjalon , Stephen Hemminger , "myravjev@amicon.ru" CC: "dev@dpdk.org" , "De Lara Guarch, Pablo" , "Richardson, Bruce" , "honnappa.nagarahalli@arm.com" , "vguvva@caviumnetworks.com" , "brijesh.s.singh@gmail.com" , "Wang, Ren" , "Gobriel, Sameh" , "Tai, Charlie" Thread-Topic: [dpdk-dev] [PATCH v5 5/8] hash: add read and write concurrency support Thread-Index: AQHUGVilFq5i3KUZRESqgFJIrUczUaSKySgwgAG3zoD//+OfcA== Date: Fri, 13 Jul 2018 01:55:20 +0000 Message-ID: References: <1528455078-328182-1-git-send-email-yipeng1.wang@intel.com> <20180711134907.01d8eaf0@xeon-e3> <4478633.7AMRLkzmKO@xps> In-Reply-To: <4478633.7AMRLkzmKO@xps> 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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTg1OTJmNDktZWFlYS00NzFkLWJiMzQtMDMyYTE3MWRkYjYzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiRWk2SFwvblpQRzJlcXBDbnM4ZGppa2FhR3JoTytnRHQyeHlNV3RTQzBmb0NpdDBweEtDNExpdTVKcW53V1hkVHYifQ== 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 v5 5/8] hash: add read and write concurrency support 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:55:24 -0000 Thanks for pointing me to this patch. I guess the try-locks still does not solve the overhead of multiple readers= contending the counter. It just provides a non-blocking version of the sa= me algorithm. The relock function looks interesting. But it would be helpful if any speci= al use case or example is given. Specifically, who should call this functio= n, the reader or the writer? Leonid, could you provide more context? The TLRW example I gave is potentially a better rw-lock algorithm. Paper Re= ference: D. Dice and N Shavit. "TLRW: return of the read-write lock". In s= uch scheme, readers won't contend the same reader counter which introduces = heavy cache bouncing that Stephen mentioned. Maybe we should introduce sim= ilar algorithm into rte_rwlock library. >-----Original Message----- >From: Thomas Monjalon [mailto:thomas@monjalon.net] >Sent: Thursday, July 12, 2018 1:30 PM >To: Wang, Yipeng1 ; Stephen Hemminger >Cc: dev@dpdk.org; De Lara Guarch, Pablo ; = Richardson, Bruce ; >honnappa.nagarahalli@arm.com; vguvva@caviumnetworks.com; brijesh.s.singh@g= mail.com; Wang, Ren ; >Gobriel, Sameh ; Tai, Charlie >Subject: Re: [dpdk-dev] [PATCH v5 5/8] hash: add read and write concurrenc= y support > >12/07/2018 03:22, Wang, Yipeng1: >> From: Stephen Hemminger [mailto:stephen@networkplumber.org] >> >> > For small windows, reader-writer locks are slower than a spin lock >> > because there are more cache bounces. >> >> Hi, Stephen, >> >> You are correct and we understand that spinlock might be slightly faster= than counter based rwlock in this case. However, the >counter based rwlock is the exception path when TSX fails. >> >> If performance of this exception path is a big concern, a more optimal r= ead-write lock scheme (e.g. TLRW) should be introduced into >rte_rwlock in the future. > >Something like this? > eal/rwlocks: Try read/write and relock write to read locks added > https://patches.dpdk.org/patch/40254/ > >