Messages in this thread |  | | Date | Thu, 5 Sep 2002 08:21:28 +0200 | From | Patrick Schaaf <> | Subject | Re: ip_conntrack_hash() problem |
| |
On Thu, Sep 05, 2002 at 10:39:40AM +1000, Rusty Russell wrote: > In message <20020904152626.A11438@wotan.suse.de> you write: > > > I think the hash function should be fixed, not the possible choice of > > > hash sizes, if that is at feasible. > > I also agree with Martin that it is better to fix the hash function in > > this case. Restricting to magic hash table sizes looks like a bad hack. > > This work is already done: > http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Netfilter/conntrack_hashing.patch.gz
Some comments:
A) secs_between_rehash is doubled every rehash, and never decreased again. This looks broken. What's the rationale? B) I despise the (1 << ...htable_bits) construct, used in several places. It's nothing but obfuscation. Please reinstate ...htable_size, and use that, the code will be more readable. C) did you measure how much time the rehashing takes, for a single run on a significant (2^16 buckets, at least) conntracking table? D) did you run your hash_conntrack() against my cttest bucket occupation simulator? Can we see comparing pictures?
To conclude, I agree with using a multiplicative hash, but I'm a bit nervous about the rehashing thing. A single random hash_base call would be enough to satisfy _my_ paranoia. IMHO the rehashing should be a compile/run time "be more paranoid" option.
best regards Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |