On Mon, 2008-21-07 at 11:17 +0800, Herbert Xu wrote:Aha - makes absolute sense then;-> 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. 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Rafael J. Wysocki | Re: Linux 2.6.27-rc5: System boot regression caused by commit a2bd7274b47124d2fc4d... |
git: | |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
