[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20150223.181544.230510782345048771.davem@davemloft.net>
Date: Mon, 23 Feb 2015 18:15:44 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: alexei.starovoitov@...il.com
Cc: paulmck@...ux.vnet.ibm.com, tgraf@...g.ch, josh@...htriplett.org,
herbert@...dor.apana.org.au, kaber@...sh.net,
ying.xue@...driver.com, netdev@...r.kernel.org,
netfilter-devel@...r.kernel.org
Subject: Re: Ottawa and slow hash-table resize
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
Date: Mon, 23 Feb 2015 15:07:20 -0800
> Also 'count of pending inserts' is going to be very small and
> meaningless, since it will count the number of threads that
> are sleeping on insert and not very useful to predict future
> expansions.
Good point.
A way around this would be to allow batching. So netfilter would
do something like:
set->ops->batch_insert_start();
nla_for_each_nested(attr, nla[NFTA_SET_ELEM_LIST_ELEMENTS], rem) {
err = nft_add_set_elem(&ctx, set, attr);
if (err < 0)
break;
set->nelems++;
}
set->ops->batch_insert_end();
And batch_insert_start and batch_insert_end would point to something
that calls new routines rhashtable_batch_insert_start() and
rhashtable_batch_insert_end().
Inside of this sequence, rhashtable_insert() calls queue to a list if
a table grow is in progress.
The pending list is processed by both rhashtable_batch_insert_end()
and table grow completion.
--
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