Re: [v2 PATCH 3/10] rhashtable: Allow hashfn to be unset
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2015-03-22 12:04:37
On Sun, Mar 22, 2015 at 11:55:05AM +0000, Thomas Graf wrote:
On 03/22/15 at 07:04pm, Herbert Xu wrote:quoted
@@ -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.
quoted
+ 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.
quoted
+ 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. Cheers, -- Email: Herbert Xu [off-list ref] Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt