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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
