Re: [RFC][PATCH] TX status reporting with help of an ack queue

[Mattias Nissler <mattias.nissler@gmx.de>]

On Mon, 2008-09-15 at 21:46 +0200, Johannes Berg wrote:
> 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.

Well, I'm a big fan of modularizing everything in a clean way. This
whole mac80211 thingy is complex enough... But I don't really care as
long as everybody here is happy with it. Let's wait what Mikko says,
it's his code so far.

> 
> > > > 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?

Retries in the hw? I don't understand? You mean that as a name?

Mattias