From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 7062D2C15 for ; Wed, 3 Oct 2018 01:57:31 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2018 16:57:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,333,1534834800"; d="scan'208";a="91629702" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga002.fm.intel.com with ESMTP; 02 Oct 2018 16:53:37 -0700 Received: from fmsmsx151.amr.corp.intel.com ([169.254.7.87]) by fmsmsx104.amr.corp.intel.com ([169.254.3.197]) with mapi id 14.03.0319.002; Tue, 2 Oct 2018 16:53:37 -0700 From: "Wang, Yipeng1" To: Honnappa Nagarahalli , "Richardson, Bruce" CC: "Ananyev, Konstantin" , "dev@dpdk.org" , "Gobriel, Sameh" , nd Thread-Topic: [PATCH v4 1/4] hash: fix race condition in iterate Thread-Index: AQHUV4tmAg2+LyLdK02sCmNUWmjPiqUK2QOwgAA8jpCAAMECgIAAzM7w Date: Tue, 2 Oct 2018 23:53:36 +0000 Message-ID: References: <1537993618-92630-1-git-send-email-yipeng1.wang@intel.com> <1538155426-145177-1-git-send-email-yipeng1.wang@intel.com> <1538155426-145177-2-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.400.15 dlp-reaction: no-action x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMDI5M2M3YWQtY2QyOS00NzhiLWE3ZGEtNGU0OTJmNzMzM2FjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiQXEwVWVqZmFKWWJRQU9IcDZZV0kxNlJoN1VyN3g5ZVVHeWsrOGh4WDFBVU52WktNUjhoRGg1dmhTZjNPV0QwMiJ9 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 v4 1/4] hash: fix race condition in iterate 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: Tue, 02 Oct 2018 23:57:32 -0000 >-----Original Message----- >From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com] >> >> /* Get position of entry in key table */ >> >> position =3D h->buckets[bucket_idx].key_idx[idx]; >> >If we change the while loop as I suggested as above, we can remove this= line. >> > >> >> next_key =3D (struct rte_hash_key *) ((char *)h->key_store + >> >> [Wang, Yipeng] Sorry that I did not realize you already have it in your = patch >> set and I agree. >> Do you want to export it as a bug fix in your patch set? I will remove m= y >> change. >Sure, I will make a separate commit for this. [Wang, Yipeng] I fixed the issue you mentioned and put it in V5 and I saw y= ou acked it. You don't need to change you patch now. >> >> For the lock free, do we need to protect it with version counter? Imagin= e the >> following corner case: >> While the iterator read the key and data, there is a writer deleted, rem= oved, >> and recycled the key-data pair, and write a new key and data into it. Wh= ile the >> writer are writing, will the reader reads out wrong key/data, or mismatc= hed >> key/data? >> >In the lock-free algorithm, the key-data is not 'freed' until the readers = have completed all their references to the 'deleted' key-data. >Hence, the writers will not be able to allocate the same key store index t= ill the readers have stopped referring to the 'deleted' key- >data. >I re-checked my ladder diagrams [1] and I could not find any issues. > >[1] https://dpdkuserspace2018.sched.com/event/G44w/lock-free-read-write-co= ncurrency-in-rtehash (PPT) [Wang, Yipeng] After checking your slides, I agree. It works with upper level application = which should have RCU-like mechanisms to ensure the grace period has finished before recycling. In this case, the logic is = good!=20 If you haven't done so, could you be more specific in doc and the API comme= nt to indicate that the key-data pair recycle function should only be calle= d after reader finished (or maybe specifically indicate RCU type of mechanism= is needed?). I feel that users not familiar with this could easily get it wrong.=20 Besides this, I don't have other concern.