lkml.org 
[lkml]   [2002]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.128 / U:1.552 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site