On Thu, Jun 28, 2012 at 12:33 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Wed, 2012-06-27 at 20:05 +0300, Arik Nemtsov wrote: > >> > 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). > > If the vif is on a different channel, the driver really should assign it > different queues and then there shouldn't be much queued up, right? > Also, if you really have >100ms latency on your queues, you have a major > problem anyway I'd think? Yea. It's all only theoretical :) > >> 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. > > That doesn't mean we can abandon the retry timers though? Then again, > maybe it does, we could start the timer only when we get the status > information I guess? I'm not really sure why the assoc timers are there now. If it's because we want to be sure we gave the peer a chance to respond, well the Tx-ack already gives us that. Waiting any longer won't help. Or does waiting in general before the next Tx help with something? (clear temporary congestion etc). > > I'm not sure I'd want to *require* this, but it sounds like a good thing > we could do to address this possible race for drivers that do support > reliable status reports? Yea. And then, if all current multi-channel drivers support Tx-ack, we can skip implemeting tx_sync. -- 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
