Re: [PATCH 20/31]: pkt_sched: Perform bulk of qdisc destruction in RCU.

[jamal <hadi@cyberus.ca>]

On Mon, 2008-21-07 at 11:17 +0800, Herbert Xu wrote:

> Unfortunately the scenario that I wrote this for requires frequent
> addition/removal.

Aha - makes absolute sense then;->

> Only if you also want to share it :) In the end I patched it to
> not share it which is much easier.

I am trying to visualize: if you dont share, you must have 256K copies
then? Assuming also you have a fast lookup since that was design intent.

> Of course if you're volunteering to write the dynamic hash table
> for actions then I'd happily switch back to sharing :)

It is a unique need like you said earlier (and would require a
medium-size surgery).
How about this: if a second user shows up with such a need I could do
it.

If you knew you had a 256K entry, then you could make
NAT_TAB_MASK to be (256K-1) and you are guaranteed to get O(1) lookup if
you dont specify indices.
I know youve patched it already -havent quiet understood how and your
current solution may be better- but one other way is to have a Kconfig
option which lets the user type the size of the nat hash table size at
kernel compile time. So then a change
of the sort:
#ifdef CONFIG_HASH_SIZE
#define NAT_TAB_MASK CONFIGURED_HASH_SIZE
#else
#define NAT_TAB_MASK 15
#endif

What do you think?

cheers,
jamal