From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id EBF7E160 for ; Wed, 3 Oct 2018 02:16:21 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2018 17:16:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,334,1534834800"; d="scan'208";a="75718659" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by fmsmga008.fm.intel.com with ESMTP; 02 Oct 2018 17:16:03 -0700 Received: from fmsmsx158.amr.corp.intel.com (10.18.116.75) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 2 Oct 2018 17:16:03 -0700 Received: from fmsmsx151.amr.corp.intel.com ([169.254.7.87]) by fmsmsx158.amr.corp.intel.com ([169.254.15.101]) with mapi id 14.03.0319.002; Tue, 2 Oct 2018 17:16:03 -0700 From: "Wang, Yipeng1" To: Honnappa Nagarahalli , "Richardson, Bruce" , "De Lara Guarch, Pablo" CC: "dev@dpdk.org" , "Gavin Hu (Arm Technology China)" , Steve Capper , Ola Liljedahl , nd , "Gobriel, Sameh" Thread-Topic: [dpdk-dev] [PATCH 3/4] hash: fix rw concurrency while moving keys Thread-Index: AQHURgTmZ0unqwDLWkeaG/7/RcGoo6UE/J/wgAUQ84CAARZ74IABp7xA Date: Wed, 3 Oct 2018 00:16:02 +0000 Message-ID: References: <1536253938-192391-1-git-send-email-honnappa.nagarahalli@arm.com> <1536253938-192391-4-git-send-email-honnappa.nagarahalli@arm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGJkYzAzNTItMmYzOC00NzFiLTkyOTEtZWFkOTRlNDcwOTFmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiS0drek9lSUdcLzdDNmR6NmJmdU84SDgzXC80SEdxY2tpUmczbmJuSlMrSGMyQjZsYXNMOEo5ZlloVkI3MFhcL2M5eCJ9 x-originating-ip: [10.1.200.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 3/4] hash: fix rw concurrency while moving keys 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: Wed, 03 Oct 2018 00:16:22 -0000 >-----Original Message----- >[Wang, Yipeng] I was thinking about another corner case and wondering if t= he version counter needs to be done on key deletion as >well. >For example, a reader reads out the index and falsely matches a signature,= before it reads out the data and the key, the key-data pair >got >deleted, removed, and recycled by another writer thread. This writer part= ially overwrote the key (because key store is too large to be >atomic). >Now, the reader begins to compare the key, and accidentally matches the ke= y (because the key is partially written and accidentally >matches), will >The reader read the wrong data out (which should have been a lookup miss)? > [Wang, Yipeng] As a second thought after reading your slides, I think the s= cenario I described above should be handled by the upper level application using RCU-like mechanisms to recycle key-data only after = the grace period. So I think it is OK. Please ignore my last comment. But if convenient, please add more comment in the API doc and in user guide= as well just in case users might not understand the restriction. Thanks Yipeng