> > Emmanuel Grumbach wrote: > > When mac80211 wants to ensure that a frame is sent, it calls the > > flush() callback. Until now, iwldvm implemented this by waiting that > > all the frames are sent (ACKed or timeout). > > In case of weak signal, this can take a significant amount of time, > > delaying the next connection (in case of roaming). > > ath9k does pretty much the same - just wait for pending frames to be > completed. > > mac80211 doesn't seem to set 'drop' anywhere when calling flush(), so ath9k > ends up waiting for frame completion in all cases too. > Maybe this might cause inordinate delays in low-signal connections with > ath9k too... >
I can't really tell... I guess it depends on the firmware / hardware. On these devices (dvm), the firmware would take a very long time to send / drop the packets. I guess it is a bug, and users have been suffering from this for a very long time. Thing is that I was educated by the "Thee shall not drop packets" mantra. But it appears that sometimes, it is very healthy to drop packets to solve the traffic jam. Here, I just drop the packets besides the VO queue to allow the roaming mgmt frames to reach their goal (I rely on the fact that the VO queue will not be too large...). TCP will retry these packets when the link will be much better after roaming. Users in bugzilla said that it improved dramatically the overall behavior. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
