[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1380040739.2736.37.camel@bwh-desktop.uk.level5networks.com>
Date: Tue, 24 Sep 2013 17:38:59 +0100
From: Ben Hutchings <bhutchings@...arflare.com>
To: David Laight <David.Laight@...LAB.COM>
CC: Tom Herbert <therbert@...gle.com>, <davem@...emloft.net>,
<netdev@...r.kernel.org>, <jesse.brandeburg@...el.com>
Subject: Re: [PATCH 1/2] net: Toeplitz library functions
On Tue, 2013-09-24 at 09:32 +0100, David Laight wrote:
> > +static inline unsigned int
> > +toeplitz_hash(const unsigned char *bytes,
> > + struct toeplitz *toeplitz, int n)
> > +{
> > + int i;
> > + unsigned int result = 0;
> > +
> > + for (i = 0; i < n; i++)
> > + result ^= toeplitz->key_cache[i][bytes[i]];
> > +
> > + return result;
> > +};
>
> That is a horrid hash function to be calculating in software.
>
> The code looks very much like a simple 32bit CRC.
> It isn't entirely clears exactly where the 'key' gets included,
> but I suspect it is just xored with the data bytes.
Each input bit is multiplied by a 32-bit slice of the key and the
products are then bitwise-summed (i.e. xored).
[...]
> I also thought the hash was arranged so that tx and rx packets
> for a single connection hash to the same value?
Not in general. I think I saw that one of the BSDs (DragonflyBSD?)
generates Toeplitz keys with this property and has an efficient software
implementation that works for those keys. But that significantly
weakens the hash.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
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