On Thu, Jun 28, 2012 at 1:10 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > 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? Yea I guess the callbacks don't hurt anyone. -- 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
