Re: [PATCH v4] mac80211: Optimize sta lookup for many VIFs

[Ben Greear <greearb@candelatech.com>]

On 04/11/2013 02:15 AM, Johannes Berg wrote:
> On Tue, 2013-04-09 at 10:35 -0700, Ben Greear wrote:
>> On 04/09/2013 02:50 AM, Johannes Berg wrote:
>>> On Fri, 2013-03-29 at 09:00 -0700, greearb@candelatech.com wrote:
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> The sta_info hash is designed to deal with an AP
>>>> with lots of stations associated, or a station interface
>>>> connected to a single AP.
>>>
>>> Given your other hash patches, does this even make sense still?
>>
>> This handles the TX side for station VIFs.  The more complicated
>> hashing handles the rx logic.  I could use the hash
>> for the tx side, though performance is likely a small bit
>> worse since you have to deal with the hash logic.
>
> Well, for the TX side in your particular case the vhash should always
> just find the right station first, so basically it's the same, no? I
> mean, if you used the new hash in the TX code, it would basically do the
> same the some_sta thing does, assuming your hash spreads well, no?

Yes, assuming good spread.  The hash spread does fail catastrophically
if the lowest MAC octet doesn't change, however.  A cure for that might
just be a smarter hash method, however.

>> And, if the more complicated RFC hashing patch has no upstream
>> chance anyway, then if the 'some-sta' patch is acceptable,
>> I'd still be interested in seeing it upstream.
>
> Well I'm debating (with myself mostly) ... The some_sta seems
> reasonable, but still a big ugly and like a special case. I'd rather not
> merge the vhash because of the various overheads, so you'd probably want
> to maintain that out of tree anyway. It seems to me that the vhash
> should address your other case pretty much just as well, so then if you
> maintain that anyway I wouldn't have to merge the some_sta patch ... I
> guess I'd kinda prefer that :-)

Well, with regard to vhash overhead, it's not that much extra code or
memory, and in the hot paths it should be no worse than the current
code as far as I can tell.

In multi-VAP cases, if we do the per-sdata vhash, you might actually see
some improvements on tx side due to less hash collisions (in real word
cases not quite as strange as mine!).

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com