lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 21 Jul 2008 07:14:39 -0400 From: jamal <hadi@...erus.ca> To: Herbert Xu <herbert@...dor.apana.org.au> Cc: kaber@...sh.net, davem@...emloft.net, netdev@...r.kernel.org, johannes@...solutions.net, linux-wireless@...r.kernel.org Subject: Re: [PATCH 20/31]: pkt_sched: Perform bulk of qdisc destruction in RCU. 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 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