Johannes Berg wrote: > On Tue, 2007-09-11 at 12:52 +0200, Michael Buesch wrote: > > On Tuesday 11 September 2007 12:29:56 Johannes Berg wrote: > > > On Tue, 2007-09-11 at 12:20 +0200, Michael Buesch wrote: > > > > > > > What about the following: > > > > We have a "the packet failed" IRQ. so we know that if that didn't > > > > raise for a packet, it must have succeed. > > > > So currently we already maintain a queue of TX packets. What about > > > > changing the handling of this queue? Instead of dropping (and > > > > telling mac80211 success) on an ACK RX, simply do a timeout. > > > > We can calculate the time (plus some additional msecs to be sure) > > > > by when an ACK must have arrived, no? > > > > > > That's tricky though, because multiple retry rates mean that it can > > > possibly take quite a while for the packet to go through. And ath5k > > > wants to support up to 7 different rates for each packet. > > > > I'm only talking about zd, though. > > Yeah, but that means the driver should implement it because it has much > less problems getting the heuristics right. Notify that the TX-failed interrupt has only the destination MAC address of the transmitted packet. So if the driver has sent two packets to the device and both are still in their timeout time, it will not be known, whether the first or the second failed. (The destination address for STAs will always be the same.) Sending only one packet until the timeout period is over is certainly doable and could be used for critical activity like association and authentication, but for normal mode the driver should only be required to provide statistics. -- Uli Kunitz - 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
