On Mon, 2008-09-15 at 21:39 +0200, Mattias Nissler wrote: > > 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. > > Just to get this straight: By queue you mean the to-be-introduced > unknown status queue? Yes. > Of course you can do it that way, but then you'll have all the flags and > data structures built into mac80211 unconditionally instead of letting > the driver developer decide. Oh, I'm fine with building them in there as long as the code paths aren't actually used for drivers that don't need them. This isn't a big thing. > > > 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. > > Ok, I don't really care how it's called as long as the one writing that > stuff chooses an appropriate name in the code :-) :) But ACK is getting confusing, we're just reporting status based on reception (or non-reception!) of ACKs :) How about retries in the hw? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
