On 9/12/07, Ulrich Kunitz <kune@xxxxxxxxxxxxxx> wrote: > 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. > That was my suggestion as well. > -- > 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
