From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Wang, Yipeng1" <yipeng1.wang@intel.com>
Subject: Re: [PATCH v4 2/4] hash: add extendable bucket feature
Date: Thu, 4 Oct 2018 01:22:17 +0000
Message-ID: <D2C4A16CA39F7F4E8E384D204491D7A6614EBB00@FMSMSX151.amr.corp.intel.com>
References: <1537993618-92630-1-git-send-email-yipeng1.wang@intel.com>
 <1538155426-145177-1-git-send-email-yipeng1.wang@intel.com>
 <1538155426-145177-3-git-send-email-yipeng1.wang@intel.com>
 <20181003080811.7c1258bc@xeon-e3>
 <D2C4A16CA39F7F4E8E384D204491D7A6614EB680@FMSMSX151.amr.corp.intel.com>
 <AM6PR08MB36727DA717E4BACAD3E6E55798E90@AM6PR08MB3672.eurprd08.prod.outlook.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "Richardson, Bruce" <bruce.richardson@intel.com>, "Ananyev, Konstantin"
 <konstantin.ananyev@intel.com>, "dev@dpdk.org" <dev@dpdk.org>, "Gobriel,
 Sameh" <sameh.gobriel@intel.com>, nd <nd@arm.com>
To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>, Stephen Hemminger
 <stephen@networkplumber.org>
Return-path: <dev-bounces@dpdk.org>
Received: from mga07.intel.com (mga07.intel.com [134.134.136.100])
 by dpdk.org (Postfix) with ESMTP id 19D3D5911
 for <dev@dpdk.org>; Thu,  4 Oct 2018 03:22:19 +0200 (CEST)
In-Reply-To: <AM6PR08MB36727DA717E4BACAD3E6E55798E90@AM6PR08MB3672.eurprd08.prod.outlook.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-----
>From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
>> >-----Original Message-----
>> >From: Stephen Hemminger [mailto:stephen@networkplumber.org]
>> >On Fri, 28 Sep 2018 10:23:44 -0700
>> >Yipeng Wang <yipeng1.wang@intel.com> wrote:
>> >
>> >> +	/* clear free extendable bucket ring and memory */
>> >> +	if (h->ext_table_support) {
>> >> +		memset(h->buckets_ext, 0, h->num_buckets *
>> >> +						sizeof(struct
>> rte_hash_bucket));
>> >> +		while (rte_ring_dequeue(h->free_ext_bkts, &ptr) =3D=3D 0)
>> >> +			rte_pause();
>> >
>> >Pause is much to short. Maybe nanosleep or sched_yield()?
>>
>> Hmm.. As a second thought, maybe we don't need any pause/sleep here?
>>
>> It is not a waiting loop and in multithreading case it is in the writer =
lock so
>> this thread Should be the only thread operating this data structure.
>>
>> What do you think?
>Yes, this is a single thread use case. This is resetting the ring.
>
[Wang, Yipeng] If people agree on this, I can have a separate patch later t=
o remove the pause.
>>
>> BTW Honnappa, in the lock free implementation, is hash_reset protected?
>> We should indicate in the API doc which API is supposed to be protected =
by
>> user.
>I do not understand the use case for hash_reset API. Why not call hash_fre=
e and hash_create?
>But, lock free implementation does not handle hash_reset. I will document =
it in the next version.
>
[Wang, Yipeng]
I assume reset maybe still faster than free and create. Also, after free, y=
ou cannot guarantee that
the creation can succeed.  It might also require less user-level code by us=
ing reset.=20
I agree that in most use cases people can just free and create a new one.