From mboxrd@z Thu Jan 1 00:00:00 1970 From: Herbert Xu Subject: Re: [PATCH net-next 2/5] rhashtable: Add rhastable_walk_peek Date: Fri, 1 Dec 2017 11:38:41 +1100 Message-ID: <20171201003841.GA26474@gondor.apana.org.au> References: <20171201000305.2392-1-tom@quantonium.net> <20171201000305.2392-3-tom@quantonium.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: davem@davemloft.net, netdev@vger.kernel.org, rohit@quantonium.net To: Tom Herbert Return-path: Received: from [128.1.224.119] ([128.1.224.119]:41562 "EHLO ringil.hmeau.com" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1750842AbdLAAir (ORCPT ); Thu, 30 Nov 2017 19:38:47 -0500 Content-Disposition: inline In-Reply-To: <20171201000305.2392-3-tom@quantonium.net> Sender: netdev-owner@vger.kernel.org List-ID: On Thu, Nov 30, 2017 at 04:03:02PM -0800, Tom Herbert wrote: > This function is like rhashtable_walk_next except that it only returns > the current element in the inter and does not advance the iter. > > This patch also creates __rhashtable_walk_find_next. It finds the next > element in the table when the entry cached in iter is NULL or at the end > of a slot. __rhashtable_walk_find_next is called from > rhashtable_walk_next and rhastable_walk_peek. > > Signed-off-by: Tom Herbert Hi Tom: Could you add some motivation for this feature into the patch description? As it is it's difficult to deduce why we would want to add something like this given that hashtable walks are always unstable and there is no guarantee that two calls to peek or a peek followed by a normal walk will see the same entry. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt