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? > 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 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? 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
