netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Graf <tgraf@suug.ch>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Patrick McHardy <kaber@trash.net>,
	Josh Triplett <josh@joshtriplett.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	netdev@vger.kernel.org
Subject: Re: [v2 PATCH 3/10] rhashtable: Allow hashfn to be unset
Date: Sun, 22 Mar 2015 12:32:57 +0000	[thread overview]
Message-ID: <20150322123257.GI1185@casper.infradead.org> (raw)
In-Reply-To: <20150322120415.GA5238@gondor.apana.org.au>

On 03/22/15 at 11:04pm, Herbert Xu wrote:
> On Sun, Mar 22, 2015 at 11:55:05AM +0000, Thomas Graf wrote:
> > On 03/22/15 at 07:04pm, Herbert Xu wrote:
> > > @@ -134,6 +136,7 @@ struct rhashtable {
> > >  	struct bucket_table __rcu	*tbl;
> > >  	atomic_t			nelems;
> > >  	bool                            being_destroyed;
> > > +	unsigned int			key_len;
> > 
> > Why is this needed? It looks like you're always initializing this
> > with ht->p.key_len
> 
> It's ht->p.key_len/4 if we use jhash2.

Sure but why not just store key_len/4 in ht->p.key_len then if you
opt in to jhash2() in rhashtable_init()?

> > > +	if (!__builtin_constant_p(params.key_len))
> > > +		hash = ht->p.hashfn(key, ht->key_len, tbl->hash_rnd);
> > 
> > I don't understand this. It looks like you only consider
> > params->key_len if it's constant.
> 
> If params->key_len is not constant, then params == ht->p.

I must be missing something obvious. Who guarantees that? I can see
that's true for the current callers but what prevents anybody from
using rhashtable_lookup_fast() with a key length not known at compile
time and pass it as rhashtable_params?

> > > +	else if (params.key_len) {
> > > +		unsigned key_len = params.key_len;
> > > +
> > > +		if (params.hashfn)
> > > +			hash = params.hashfn(key, key_len, tbl->hash_rnd);
> > > +		else if (key_len & (sizeof(u32) - 1))
> > > +			hash = jhash(key, key_len, tbl->hash_rnd);
> > > +		else
> > > +			hash = jhash2(key, key_len / sizeof(u32),
> > > +				      tbl->hash_rnd);
> > > +	} else {
> > > +		unsigned key_len = ht->p.key_len;
> > > +
> > > +		if (params.hashfn)
> > > +			hash = params.hashfn(key, key_len, tbl->hash_rnd);
> > > +		else
> > > +			hash = jhash(key, key_len, tbl->hash_rnd);
> > 
> > Why don't we opt-in to jhash2 in this case?
> 
> Because if key_len == 0 it means that key_len is not known at
> compile-time.

I still don't get this. Why do we fall back to jhash2() if
params.key_len is set but not if only ht->p.key_len is set?

  reply	other threads:[~2015-03-22 12:32 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-22  8:03 [v2 PATCH 0/10] rhashtable: Multiple rehashing Herbert Xu
2015-03-22  8:03 ` [v2 PATCH 1/10] rhashtable: Add barrier to ensure we see new tables in walker Herbert Xu
2015-03-22 10:47   ` Thomas Graf
2015-03-22  8:04 ` [v2 PATCH 2/10] rhashtable: Eliminate unnecessary branch in rht_key_hashfn Herbert Xu
2015-03-22 11:07   ` Thomas Graf
2015-03-22  8:04 ` [v2 PATCH 3/10] rhashtable: Allow hashfn to be unset Herbert Xu
2015-03-22 11:55   ` Thomas Graf
2015-03-22 12:04     ` Herbert Xu
2015-03-22 12:32       ` Thomas Graf [this message]
2015-03-22 21:12         ` Herbert Xu
2015-03-23  9:58           ` Thomas Graf
2015-03-23 10:18             ` Herbert Xu
2015-03-23 14:29   ` David Laight
2015-03-22  8:04 ` [v2 PATCH 4/10] netlink: Use default rhashtable hashfn Herbert Xu
2015-03-22 11:55   ` Thomas Graf
2015-03-23  1:18   ` Simon Horman
2015-03-23 12:56     ` Herbert Xu
2015-03-22  8:04 ` [v2 PATCH 5/10] tipc: " Herbert Xu
2015-03-22 11:56   ` Thomas Graf
2015-03-22  8:04 ` [v2 PATCH 6/10] netfilter: " Herbert Xu
2015-03-22 11:56   ` Thomas Graf
2015-03-23 11:32     ` Herbert Xu
2015-03-22  8:04 ` [v2 PATCH 7/10] rhashtable: Disable automatic shrinking Herbert Xu
2015-03-22 12:17   ` Thomas Graf
2015-03-22 13:06     ` Thomas Graf
2015-03-23  0:07       ` Herbert Xu
2015-03-23  8:37         ` Thomas Graf
2015-03-23  9:29           ` Herbert Xu
2015-03-23  9:43             ` Thomas Graf
2015-03-23  0:09     ` Herbert Xu
2015-03-23  8:33       ` Thomas Graf
2015-03-23  9:28         ` Herbert Xu
2015-03-23  9:36           ` Thomas Graf
2015-03-23  9:39             ` Herbert Xu
2015-03-23  9:44               ` Herbert Xu
2015-03-23 10:08                 ` Thomas Graf
2015-03-23 10:19                   ` Herbert Xu
2015-03-23 16:45           ` David Miller
2015-03-23 16:44         ` David Miller
2015-03-23 21:48           ` Herbert Xu
2015-03-23 22:13           ` Thomas Graf
2015-03-22  8:04 ` [v2 PATCH 8/10] rhashtable: Add multiple rehash support Herbert Xu
2015-03-22  8:04 ` [v2 PATCH 9/10] rhashtable: Allow GFP_ATOMIC bucket table allocation Herbert Xu
2015-03-22  8:04 ` [v2 PATCH 10/10] rhashtable: Add immediate rehash during insertion Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150322123257.GI1185@casper.infradead.org \
    --to=tgraf@suug.ch \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=josh@joshtriplett.org \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).