On Mon, 2008-10-20 at 23:33 +0530, Sujith wrote: > > Can you explain the way it currently works in ath9k? > > > > Alright, it goes something like this: Thanks. > * mac80211 sends down a frame > * Initiate an aggregation session for the <RA,TID> if one isn't already in progress. It seems that should be a rate control decision? Possibly taking into account more than just always doing aggregation sessions. Then again, I suppose aggregation sessions are cheap. What about latency here? > * Pause the TID, i.e, add further frames to the TID's queue. > * If ADDBA exchange is successful, resume TID. > * Form aggregates from the TID's buffer list, send them out. > ( Take care to maintain minimum HW queue depth for aggregation ) "maintain minimum HW queue depth"? In what way? You mean put in enough frames? > * If ADDBA exchange fails, flush TID. > * Send TID's pending frames as normal frames (non-ampdu) Obviously. But why isn't this done in parallel? I mean, why not send out the frame and do addba and don't aggregate until addba was successful, that would mean no latency for those frames... addba could even time out which would add a lot of latency, no? > Now, assuming we have a successful aggregation session going, > frame handling looks like this: > > * mac80211 sends down a frame > * Append to TID's buffer list. > > On TX Completion, > > * Process all TX queues > * Process all complete descriptors. > * Complete all sub-frames of an aggregate that were ACKed (send status to mac80211). > * Re-queue sub-frames that were not ACKed back to the TID's pending queue. > * Schedule this TID for processing. Those have to go in front of the queue, right? So they're sent out next? > * Run through all scheduled TIDs > * Form aggregates from the pending buffers and send them out. > ( Again, maintain minimum HW depth ) Which TIDs are "scheduled"? > So, aggregation is currently done on a need-to basis, and changing this > to a flow where mac80211 sends down frames with A-MPDU related control information > would mean a complete rewrite of ath9k's TX path. :-) So what? :) I'm trying to avoid having to do all this again and again in b43, rt2x00 etc. The hw really behaves very similarly. > > Also, I'm trying to understand the relation between a block-ack > > agreement and A-MDPU, I understand that without a block-ack-agreement > > aggregation isn't very useful, but could we not, for example, implement > > (regular) delayed block-ack with much the same infrastructure? > > > > Immediate Block-Ack is mandatory for 11n, delayed BA is optional. > ath9k currently maintains the BA window state internally too. > Another candidate that can be moved to mac80211, IMO. Yeah, I agree. There's information on this in the tx status even I think. > > What I could also imagine is that mac80211 simply does pretty much > > everything and hands a number of skbs to the driver at once with some > > additional information about how to aggregate them, what sort of spacing > > to use, etc. It should be able to calculate all the required stuff since > > it knows from the rate control algorithm what's happening there. That > > might leave Intel out a bit, but I'm starting to think that we want to > > special-case them a bit anyway. > > Well, I really don't know how this would affect performance, but > I think this _might_ be a better model. Where would you see it have a noticeable effect on performance? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
