From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [v1 PATCH 2/7] rhashtable: Allow hash/comparison functions to be inlined Date: Fri, 20 Mar 2015 12:06:32 +0000 Message-ID: <20150320120632.GJ28736@acer.localdomain> References: <20150320105421.GA18148@gondor.apana.org.au> <20150320112041.GF28736@acer.localdomain> <20150320120228.GA18736@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "David S. Miller" , Thomas Graf , Eric Dumazet , netdev@vger.kernel.org To: Herbert Xu Return-path: Received: from stinky.trash.net ([213.144.137.162]:36087 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750932AbbCTMGh (ORCPT ); Fri, 20 Mar 2015 08:06:37 -0400 Content-Disposition: inline In-Reply-To: <20150320120228.GA18736@gondor.apana.org.au> Sender: netdev-owner@vger.kernel.org List-ID: On 20.03, Herbert Xu wrote: > On Fri, Mar 20, 2015 at 11:20:42AM +0000, Patrick McHardy wrote: > > > > I haven't checked in detail yet whether this still satisfies what > > we need in nftables, just a minor comment below: > > AFAIK I have done nothing to break multiple keys as yet and > the comparison function is still there, just embedded into the > params structure. Yep, seems fine on a quick skim, but it will take until tonight before I can have a closer look. > > > +struct rhashtable_compare_arg { > > > + struct rhashtable *ht; > > > + const void *key; > > > +}; > > > > I found it a bit odd in the old interface that elementary data > > such as the key for comparision is encapsulated into a structure > > instead of passed as a function argument. Is there a reason > > for not passing both as arguments so we can at least avoid the > > encapsulation for the common case? > > I don't have any objections against changing it but it could > be done outside of this particular patch-set. Absolutely. Just thought I mention it since you already touched all relevant parts.