On Mon, 2008-09-15 at 20:03 +0200, Johannes Berg wrote:

quoted

2. Make the ACK queue approach generic and wrap it in some library
functions that become part of mac80211 and are called from the driver's
tx and rx handlers, respectively. This has the advantage that it is less
invasive than 1. It is essentially what Ivo has described above. Driver
writers would be free to use this framework, but are not required to do
so.

I think this is what we want.

Ok. If we take this path I think we do not need to add more flags to
mac80211 and the drivers that enable special processing w.r.t. the
device packet filters (as suggested by Ivo previously). Instead, the
driver itself should take whatever action is necessary to tell the
hardware to deliver ACK frames. Johannes, could you recap for me
whether the driver should report these additional ACKs to mac80211 or
keep quiet if they weren't requested?

quoted

quoted

quoted

This doesn't use timers so a message might in theory be
stuck in the queue indefinitely.

Well you wouldn't need timers actually, if you have a list of packets
waiting to be acked you can expect the frames to be acked in the order
of which they were send (when using the same queue).

Yes, hence you have to keep track of things per queue.

Good point :-) So I suggest we have one function that adds new packets
to the ACK queue (which is represented by a struct an instance of which
a driver can keep in its queue information) and another one that matches
a received ACK with the queue, reports the status to mac80211 and purges
the queue entries up to the match (reporting them as failed).

Mikko: I could hack this up, but since your initial patch is not far
from what's been discussed, I rather wait for a comment on whether you
want to do it.

Mattias