David S. Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Tue, 08 Nov 2005 11:33:16 -0800
Is there a test case I may have missed - otherwise it looks like it
was adding much randomness - particularly in the case of the IP's
being "close" to one another - the xor tends to "knock-out" the
upper bits of the IPs. And even when the remote IPs were random,
the two seemed to produce quite similar results.
You might wish to make sure you try your tests on both
big and little endian systems, trying sizes such as 8-bit
hash size masks up to something like 16-bit ones.
Somewhere deep in the history is the change where Alexey
Kuznetsov added those xor+shift statements, noting in the
changelog how without it the hash works well on big-endian
(which is where I wrote it) but fails spectacularly on
little-endian.
Ah, endianness - indeed the first set of runs were on a big-endian system. Here
are a couple runs on a little-endian system:
sweb142:/home/raj# ./hash `expr 128 \* 1024` 192.168.1.1 80 192.168.1.2 49152
131072
Hello, about to run the hash functions with:
size 131072 laddr 101a8c0 lport 80 faddr 201a8c0 fport 49152 to 65535
131072 remotes
The orig hash went from 114688 to 131071 max chain 9 used 16383 buckets
The no h shift hash went from 49152 to 65535 max chain 9 used 16383 buckets
sweb142:/home/raj# ./hash `expr 128 \* 1024` 192.168.1.1 80 255.255.255.255
49152 131072
Hello, about to run the hash functions with:
size 131072 laddr 101a8c0 lport 80 faddr ffffffff fport 49152 to 65535
131072 remotes
The orig hash went from 1 to 131069 max chain 8 used 82709 buckets
The no h shift hash went from 0 to 131071 max chain 8 used 82974 buckets
Here is an 8 bit hash size:
sweb142:/home/raj# ./hash 256 192.168.1.1 80 255.255.255.255 49152 131072Hello,
about to run the hash functions with:
size 256 laddr 101a8c0 lport 80 faddr ffffffff fport 49152 to 65535
131072 remotes
The orig hash went from 0 to 255 max chain 582 used 256 buckets
The no h shift hash went from 0 to 255 max chain 567 used 256 buckets
sweb142:/home/raj# ./hash 256 192.168.1.1 80 192.168.1.2 49152 131072
Hello, about to run the hash functions with:
size 256 laddr 101a8c0 lport 80 faddr 201a8c0 fport 49152 to 65535
131072 remotes
The orig hash went from 0 to 255 max chain 513 used 256 buckets
The no h shift hash went from 0 to 255 max chain 513 used 256 buckets
here is a 16 bit hash size:
sweb142:/home/raj# ./hash 65536 192.168.1.1 80 192.168.1.2 49152 131072
Hello, about to run the hash functions with:
size 65536 laddr 101a8c0 lport 80 faddr 201a8c0 fport 49152 to 65535
131072 remotes
The orig hash went from 49152 to 65535 max chain 9 used 16383 buckets
The no h shift hash went from 49152 to 65535 max chain 9 used 16383 buckets
sweb142:/home/raj# ./hash 65536 192.168.1.1 80 255.255.255.255 49152 131072
Hello, about to run the hash functions with:
size 65536 laddr 101a8c0 lport 80 faddr ffffffff fport 49152 to 65535
131072 remotes
The orig hash went from 0 to 65534 max chain 10 used 56748 buckets
The no h shift hash went from 0 to 65535 max chain 11 used 56611 buckets
sweb142:/home/raj# uname -a
Linux sweb142 2.6.14-rc2-gaa55a086 #2 SMP Thu Sep 29 15:12:39 PDT 2005 ia64
GNU/Linux
Still seems to be doing as well - I'm assuming that when the "random" IPs are
generated that they do not have to be put into network byte order, since they
are randomly generated bits. When the IPs aren't random, the inet_addr() call
is putting things in network byte order.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
