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? > 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 :-) johannes -- 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
