On Sat, Mar 28, 2009 at 1:42 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Sat, 2009-03-28 at 13:26 -0700, Luis R. Rodriguez wrote: >> >> OK I see that but I am not sure of what's done to the skb in the old >> >> case if the session is note complete yet, nor now if the session gets >> >> declined. I can check later, right now I'm feeling lazy. >> > >> > Before my patch the skb is still passed to the driver, which would need >> > to be able to handle it (it == session being stopped). I'm not entirely >> > sure ath9k handles it properly but I suspect it does. >> >> Not sure, this begs the question when you were seeing the received >> addba response come up first. SInce both iwlagn and ath9k use the irq >> safe aggregation cb I was suspecting this would happen in general on >> UP boxen and probably even less likely to happen on ath9k as we don't >> have to talk to the firmware during the ampdu start action. > > No, it can only happen when the remote station is faster to reply than > the driver. 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. 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. 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? 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
