Thread (35 messages) 35 messages, 7 authors, 2008-10-19

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

From: Mattias Nissler <hidden>
Date: 2008-09-15 19:39:17

On Mon, 2008-09-15 at 21:21 +0200, Johannes Berg wrote:
On Mon, 2008-09-15 at 21:00 +0200, Mattias Nissler wrote:
quoted
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.
Just to get this straight: By queue you mean the to-be-introduced
unknown status queue?

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.
quoted
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.
Ok, that's what I meant.
quoted
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 :-)

Mattias
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help