Re: Question about tcp hash function tcp_hashfn()

[Evgeniy Polyakov]

On Wed, May 31, 2006 at 03:51:24AM -0600, Brian F. G. Bidulock (bidulock@xxxxxxxxxxx) wrote:
> Evgeniy,
> 
> On Wed, 31 May 2006, Evgeniy Polyakov wrote:
> > 2. Compared Jenkins hash with XOR hash used in TCP socket selection code.
> > http://tservice.net.ru/~s0mbre/blog/2006/05/14#2006_05_14
> 
> Two problems with the comparison:
> 
>   Port numbers can be collected into a 32 bit register in network
>   byte order directly from the TCP packet without taking two 16 bit
>   values and shifting and or'ing them.

They are.

u32 ports;

ports = lport;
ports <<= 16;
ports |= fport;

>   Worse: he folded the jenkins algorith result with
> 
>    h ^= h >> 16;
>    h ^= h >> 8;
> 
>   Destroying the coverage of the function.

It was done to simulate socket code which uses the same folding.
Leaving 32bit space is just wrong, consider hash table size with that
index.

> I, for one, am not suprised that artifacts appeared in the comparison
> as a result of this destruction of the coverage of the hashing function.

It is comparison of the approach used in TCP hashing code, it is not full 
mathematical analysis. And in that case jenkins hash already not good. 
I'm sure it can be tuned, but it does require a lot of iterations, while
XOR one "just works".

-- 
	Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/