On Tue, 2015-02-24 at 00:26 +0300, Sergey Ryazanov wrote:
> > Well - not sure what you're trying to say? First you're saying jhash()
> > was clearly better and then you're saying I shouldn't use it? ;-)
> >
> In first case, I mean the jhash _algorithm_, which has a better
> distribution, in second case I mean the _generic_ jhash() _function_
> and express my doubts about its performance. See below.
Ah.
> I agree that hashing all octets is not a drawback. But the jhash()
> function is tailored to the input data of variable length, while we
> have a vector of fixed length and appropriate functions. Could we do
> the hashing in following way:
>
> u32 sta_info_hash(void *addr, u32 len, u32 seed)
> {
> u32 *k = addr + 2;
> return jhash_1word(*k, seed);
> }
This would work, but without the LA bit obviously.
> or even (to account LA bit):
>
> u32 sta_info_hash(void *addr, u32 len, u32 seed)
> {
> u32 *k = addr;
> return jhash_2words(k[0], k[1], seed);
> }
This won't exactly work as there's no known padding there so that k[1]
accesses invalid data, but I get the point. It should then be
> This could save a couple of CPU circles and a couple of bytes in the
> output image :)
I don't think it would save bytes? The jhash function is common after
all. Ah, but it's an inline, so it would be generated here.
We also can't rely on 4-byte alignment though, so perhaps we should do
something like
u32 sta_info_hash(void *addr, u32 len, u32 seed)
{
u16 *a = addr;
return jhash_3words(a[0], a[1], a[2], seed);
}
instead? Not sure what effect that has on jhash though if we don't have
anything in the high 16 bits.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
