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@xxxxxxxxxxxxxxx wrote:
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
