Re: [RFC] mac80211: Re-enable aggregation

["Tomas Winkler" <tomasw@gmail.com>]

On Mon, Oct 20, 2008 at 8:03 PM, Sujith <m.sujith@gmail.com> 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