On Mon, Oct 20, 2008 at 8:03 PM, Sujith <m.sujith@xxxxxxxxx> wrote: > Johannes Berg wrote: >> > Probably because 11n aggregation have more rigorous timing requirements >> > between frames. >> >> What kind? I can only find the ampdu spacing/length exponent stuff. >> > > I am not sure, either. > >> > > I guess there's no clear answer here. How about "whichever you want"? >> > > Though I think I prefer pushing them down as that makes the model easier >> > > to understand. It probably also makes the Intel case easier to >> > > implement. >> > >> > A way to pull down buffered frames for each TID (like ieee80211_get_buffered_bc() ) >> > would be really useful for ath9k. >> >> I'm not sure, that seems like a useful thing initially, but leaves a lot >> of stuff for the driver. We should probably think about moving more >> things *up* into mac80211 rather than giving the driver more access to >> low-level details. This would also allow us possibly even send A-MPDU >> mcast when acting as an HT AP, something the driver cannot easily do. >> >> Can you explain the way it currently works in ath9k? >> > > Alright, it goes something like this: > > * mac80211 sends down a frame > * Initiate an aggregation session for the <RA,TID> if one isn't already in progress. > * 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 ) > * If ADDBA exchange fails, flush TID. > * Send TID's pending frames as normal frames (non-ampdu) > > 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. > * Run through all scheduled TIDs > * Form aggregates from the pending buffers and send them out. > ( Again, maintain minimum HW depth ) > > 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. :-) > We may fit into this schema, just some of the book keeping tasks here we have off loaded to the hw. >> 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. > TX or RX side? >> 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. What you need is to compute how many frames can be transmitted within TXOP i think we can provide the calculation depending on the current state. Just with the retransmission down scaling need to be taken into account. That >> might leave Intel out a bit, but I'm starting to think that we want to >> special-case them a bit anyway. Let's see first mvel and bcom implementation :) > Well, I really don't know how this would affect performance, but > I think this _might_ be a better model. > > Sujith > Tomas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
