On Sat, Mar 28, 2009 at 2:17 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Sat, 2009-03-28 at 14:06 -0700, Luis R. Rodriguez wrote: > >> My point was that if you have the tasklet handled by a separate CPU >> the DRV flag would most likely be set by the time the addba response >> comes back. On a UP box though you have no option but to wait for wait >> for it to be done after we send off the addba request so then it is a >> race between the scheduler to schedule the tasklet and the remote >> station's speed + the IRQ processing of the received response. > > Ah, I see what you mean. But this goes off the same tasklet :) so ath9k > doesn't have a problem in any case. :D >> If we would somehow be able to ensure pending BHs complete before we >> process the addba response this wouldn't be needed in both places. > > No, we can't ensure that -- the driver might very well take longer and > we don't have a way to only process the received frame later. Well as you pointed out we already do since its on the same tasklet -- the delay will happen within the ampdu start action in the driver, not the irqsafe callback itself. >> Anyway I'm also stating that its likely that the ampdu start action is >> slower with iwlagn as interaction with the firmware is required so I >> would suspect one can see this behavior more likely on UP iwlagn >> boxen. >> >> Where did you see it? > > I didn't actually see it :) But iwlagn can possibly flush the queue > before calling back to the cb. Heh, flush what queue? A virtual ampdu queue thing? Or something else, I'm trying to understand exactly where this would happen, I don't think I get the picture yet. Luis -- 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
