On Mon, Mar 18, 2002 at 10:58:20PM +0100, Patrick Schaaf wrote: > Hashing with chaining is fine, but for high performance, you want the > chains only as a backdrop for the occasional hash collision. The "planned" > oversubscription of the ip_conntrack hash table (1:8 hashsize/conntrack_max) > does not perform well when conntrack_max is near. This will become more > apparent as more people try to use conntracking at the line rate their > hardware permits.
I totally agree. > On machines where I expect many connections, I'd use a hashsize > near the number of expected connections, and make conntrack_max > only about two times that value. But this obviously only helps if the hash function is distributing the conntrack entries equally among the hash buckets. I wouldn't be so sure if this really does happen when the hash becomes wider than a certain point. > How does the core team feel about this issue? I hereby suggest changing > the default calculation to have hashsize == conntrack_max/2. Were there > good reasons to do different? This would be fine with me, but rather than just blindly doing that, I'd be more interested in how good our hash function is with real world traffic. And real-world traffic usually means narrow source ip ranges (because most people firewall a couple of Class-C's) and narrow source port ranges (let's assume lots of users aren't causing too many connections and thus the source port range stays close to the startup default port (32k?)) The destination ports are most definitely also not very distributed, since most people will do the same services (http, ftp, smtp, or whatever is used from within this organization). > best regards > Patrick -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+ V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)
