From mboxrd@z Thu Jan  1 00:00:00 1970
From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
Subject: Re: [PATCH 3/4] hash: fix rw concurrency while moving
	keys
Date: Wed, 3 Oct 2018 17:39:13 +0000
Message-ID: <AM6PR08MB3672B8F0700ADF4E950CB18998E90@AM6PR08MB3672.eurprd08.prod.outlook.com>
References: <1536253938-192391-1-git-send-email-honnappa.nagarahalli@arm.com>
 <1536253938-192391-4-git-send-email-honnappa.nagarahalli@arm.com>
 <D2C4A16CA39F7F4E8E384D204491D7A6614D81EE@FMSMSX151.amr.corp.intel.com>
 <AM6PR08MB36724E09B9AF737412D166C598EE0@AM6PR08MB3672.eurprd08.prod.outlook.com>
 <D2C4A16CA39F7F4E8E384D204491D7A6614EB0E3@FMSMSX151.amr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "dev@dpdk.org" <dev@dpdk.org>, "Gavin Hu (Arm Technology China)"
 <Gavin.Hu@arm.com>, Steve Capper <Steve.Capper@arm.com>, Ola Liljedahl
 <Ola.Liljedahl@arm.com>, nd <nd@arm.com>, "Gobriel, Sameh"
 <sameh.gobriel@intel.com>
To: "Wang, Yipeng1" <yipeng1.wang@intel.com>, "Richardson, Bruce"
 <bruce.richardson@intel.com>, "De Lara Guarch, Pablo"
 <pablo.de.lara.guarch@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from EUR03-AM5-obe.outbound.protection.outlook.com
 (mail-eopbgr30050.outbound.protection.outlook.com [40.107.3.50])
 by dpdk.org (Postfix) with ESMTP id 020AA5F25
 for <dev@dpdk.org>; Wed,  3 Oct 2018 19:39:15 +0200 (CEST)
In-Reply-To: <D2C4A16CA39F7F4E8E384D204491D7A6614EB0E3@FMSMSX151.amr.corp.intel.com>
Content-Language: en-US
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

> >-----Original Message-----
> >[Wang, Yipeng] I was thinking about another corner case and wondering
> >if the 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 partially overwrote the key (because key store is too large to be
> atomic).
> >Now, the reader begins to compare the key, and accidentally matches the
> >key (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
> scenario I described above should be handled by the upper level applicati=
on
> using RCU-like mechanisms to recycle key-data only after the grace period=
.
> So I think it is OK. Please ignore my last comment.
>=20
> 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.
>=20
Agree, it needs careful documentation. I plan to change the documentation a=
fter the patch is completed.

> Thanks
> Yipeng