On Mon, 2008-09-15 at 21:00 +0200, Mattias Nissler wrote: > 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. Yes, but we could also make the ack queue processing part of mac80211, i.e. we stick the packet on the queue before ->tx() and add a few new flags to the status callback which can then process the queue. > Johannes, could you recap for me > whether the driver should report these additional ACKs to mac80211 or > keep quiet if they weren't requested? This is largely theoretical right now as mac80211 is _always_ requesting status reports via IEEE80211_TX_CTL_REQ_TX_STATUS. This is something I can't talk much about, you helped designed the rate control algorithm and I think you're in a much better position to evaluate how this should work with respect to rate control. Then again, I think I'm misunderstanding you, are you thinking whether it should hand those frames to mac80211? It doesn't matter to mac80211, to be honest. > 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). can we stop talking about "ACK queue"? It really is a "unknown status queue" or something like that. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
