[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070220193632.GA5590@2ka.mipt.ru>
Date: Tue, 20 Feb 2007 22:36:32 +0300
From: Evgeniy Polyakov <johnpol@....mipt.ru>
To: Eric Dumazet <dada1@...mosbay.com>
Cc: "Michael K. Edwards" <medwards.linux@...il.com>,
David Miller <davem@...emloft.net>, akepner@....com,
linux@...izon.com, netdev@...r.kernel.org, bcrl@...ck.org
Subject: Re: Extensible hashing and RCU
On Tue, Feb 20, 2007 at 08:17:31PM +0100, Eric Dumazet (dada1@...mosbay.com) wrote:
> I shown your test was bogus. All your claims are just bogus.
> I claim your 'true random data' is a joke. rand() in your program is a pure
> joke.
Care to reread your mail about your true random case with hash chain
length of 3 and 4? Anyway, I just shown that jenkins hash is simple to
crack and to find its collisions - even if you will put there some
constant value it will be the same. It is math, not something special
speculation about input values.
> Given 48 bits of input, you *can* find a lot of addr/port to hit one
> particular cache line if XOR function is used. With jhash, without knowing
> the 32bits random secret, you *cant*.
You seems to do not want to understand that it is exactly the same as
searching for collision law. It is simple, and results will be
dangerous.
> Again, you dont take into account the chain length.
>
> If all chains were of length <= 1, then yes, xor would be faster. In real
> life, we *know* chain length can be larger, especially in DOS situations.
I.e. you propose to add a hash, which has broken case for the same ip
addresses and different ports compared to good xor?
It was shown that hash(const, const, non_const) ends up with _broken_
distribution comapred to xor hash.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists