[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150323165033.GD20752@casper.infradead.org>
Date: Mon, 23 Mar 2015 16:50:33 +0000
From: Thomas Graf <tgraf@...g.ch>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <eric.dumazet@...il.com>,
Patrick McHardy <kaber@...sh.net>,
Josh Triplett <josh@...htriplett.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
netdev@...r.kernel.org
Subject: Re: [v3 PATCH 9/9] rhashtable: Add immediate rehash during insertion
On 03/24/15 at 12:50am, Herbert Xu wrote:
> @@ -116,6 +117,7 @@ struct rhashtable_params {
> unsigned int max_size;
> unsigned int min_size;
> u32 nulls_base;
> + bool insecure_elasticity;
> size_t locks_mul;
> rht_hashfn_t hashfn;
> rht_obj_hashfn_t obj_hashfn;
First of all, love the naming of this variable ;-)
> @@ -127,6 +129,7 @@ struct rhashtable_params {
> * @tbl: Bucket table
> * @nelems: Number of elements in table
> * @key_len: Key length for hashfn
> + * @elasticity: Maximum chain length before rehash
> * @p: Configuration parameters
> * @run_work: Deferred worker to expand/shrink asynchronously
> * @mutex: Mutex to protect current/future table swapping
2nd: Seems like you rely on an underflow to allow to "disable"
the elasticity limit. Fair enough, but it would be great to
have the limit configurable as well.
How about making elasticity a signed int, default to 16 if user
specifies 0 and require it to be set to -1 (through a define)
to actually disable the behaviour. That would avoid requiring
two variables to implement this and makes the limit configurable
at the same time.
Otherwise this looks good to me.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists