On Mon, 2008-09-15 at 19:56 +0200, Mattias Nissler wrote: > [ I've added Johannes to the CC, I hope he can provide us with some more > informed comments regarding mac80211 architecture ] I'd actually written half a reply but then decided to give up on it for now, what do you want to know? we currently use status reporting for three things: * hostapd needs to know whether some frames were acked * the rate control algorithms use it * we only report sent frames on monitor interfaces when we get a status report and incorporate information from the status report > I've also spent some time thinking about this. IMHO, he difficult part > is to come up with an interface between mac80211 and the driver which is > convenient to use for driver writers and integrates well with mac80211. > The following ideas came to my mind: > > 1. Add another callback to struct ieee80211_ops that would be used for > TX frame housekeeping. The standard implementation would just pass the > frame on the regular tx handler, but we could provide an alternate > implementation that keeps track of the packets we are expecting ACKs for > before handing the packet to the hardware. Similarly, the RX path would > provide new functions in addition to the existing ieee80211_rx[_irqsafe] > handlers that would do the matching ACK matching and pass the packet on > to ieee80211_rx() afterwards. That seems way too much overhead, but we definitely want to use the IEEE80211_TX_CTL_REQ_TX_STATUS less in the future (we currently always set it). I suppose by "expect ACKs for" you mean "expect status information for"? > 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. > 3. Make mac80211 unconditionally keep track about the packets it has > passed down to the driver and do TX status matching on all ACKs that are > received in the mac80211 rx path. (Note that this has the tendency of > duplicating the ring buffers that most drivers probably already have for > their TX queues. Maybe introduce a generic ring buffer framework and > allow the drivers to store private data in data and that?) The advantage > of this approach is that mac80211 has information about all packets that > are still in processing (don't know if that actually helps) and it's > more convenient for driver writers. I think this punishes hardware that can provide all information needlessly imho. Also, with drivers that do provide the information we don't need to process control packets at all which is good (if not necessary) for drivers on slow busses. > > > 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. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
