Re: [RFC] mac80211: Re-enable aggregation

[Sujith <m.sujith@gmail.com>]

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. :-)

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

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

Sujith