On Wed, Jun 27, 2012 at 6:25 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Wed, 2012-06-27 at 18:20 +0300, Arik Nemtsov wrote: > >> > It'll depend on the driver I guess? If you're going to set a flag "give >> > this vif priority now" on the first invocation, then you probably >> > wouldn't care about the timing. It looks like our implementation would >> > actually start some "give me the channel" operation and when the >> > firmware says "ok you have the channel now" we'd return and rely on >> > getting the TX right after. >> > >> > Wrt. the race, this isn't going to be something that happens within less >> > than a millisecond or so, it's going to give us maybe 50ms at least of >> > channel time (WFA mandates replying within 30ms), so that doesn't seem >> > like a problem? >> >> It's probably not an issue. Just seems simpler to just give the skb to >> the driver so it can do whatever it wants before/during/after. Bypass >> op_tx completely for these. > > Yeah, that was one of the other options I considered in my original > email ... but this call must be able to sleep, and the TX processing in > mac80211 cannot sleep, so unless we bypass all processing (which seems > wrong) that would be rather difficult to implement. Good point. But another race to consider the the multi-channel/multi-vif scenario, where the driver already has a lot of packets queued up, so the time will expire before we get a chance to Tx. Again this is not a problem in practice (since it's the VO ac). How about somehow requiring a multi channel driver to give always Tx-ack? That will mean we can abandon the retry timers, and rely on the driver to give an answer within a reasonable time. -- 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
