On Thu, 2012-06-28 at 13:01 +0300, Arik Nemtsov wrote: > >> 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). Well the only timer there is is retrying the frame. Arguably that isn't needed as the frame has been retried on the air already multiple times by the hardware, but sometimes temporary channel conditions exist so waiting 100ms until the next retry can make sense. If we actually receive a response, we cancel all timers right away. > > 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. We could, but I'm not sure I'd go there? It would mean that the driver has to buffer the frame, schedule a work to do whatever it needs to sync up, and then at the end of the work TX the frame. Since this only comes in from contexts in mac80211 that can sleep, from a whole system complexity POV it seems much simpler to give the driver a chance to do whatever it needs to do before the TX even happens? 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
