Re: [RFC] mac80211: use rhashtable for station table

[Johannes Berg <johannes@sipsolutions.net>]

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