[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1380025474.3165.46.camel@edumazet-glaptop>
Date: Tue, 24 Sep 2013 05:24:34 -0700
From: Eric Dumazet <eric.dumazet@...il.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.
>
> Using in it hardware is probably fine - the hardware can do
> it cheaply (in dedicated logic) as the frame arrives.
> The CRC polynomial probably collapses to a few XOR operations
> when done byte by byte (the hdlc crc16 collapses to 3 levels
> of xor).
>
> IIRC jhash() works on 32bit quantities - so has far fewer
> maths operations and well as not having all the random data
> accesses (cache misses and displacing other parts of the
> working set from the cache).
Anyway, I really hope Toeplitz hash is not restricted to 0-255 range
Tom implementation is not Toeplitz, but a degenerated hash.
--
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