On Thu, Apr 7, 2011 at 5:21 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Thu, 2011-04-07 at 17:17 +0530, Vivek Natarajan wrote: > >> > I'm not sure I understand. Where does the 100ms come from? This code >> > flushes the TX queues, which can take as much time as it wants, no? How >> > does it break applications? >> >> 100ms is the time after which the dynamic ps timer stops the netif >> queues and flushes all the frames in the driver. Actually two factors >> caused the application to timeout: >> One is the delay in the flush() for which the netif queues are >> stopped and eventually the application could not send out the frames. >> The second is the dropping of frames in the flush() callback when it >> reaches the timeout period. > > Is that an ath9k specific thing? mac80211 never invokes flush() with > drop=true, at this point. I thought we needed it and added it, but I > guess we don't really need it. Currently, ath9k gives a timeout of 200 ms for the pending frames to complete. After this timeout, the pending frames will be dropped even if drop is set as false in mac80211. Vivek. -- 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
