Re: [RFC] mac80211: Re-enable aggregation

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

On Wed, Oct 22, 2008 at 12:03 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2008-10-20 at 23:46 +0200, Tomas Winkler wrote:
>
>> > 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?

>
> Both? What exactly does your firmware do, say of the list that Sujith
> posted?
>

It answers BA i n RX path and interpret BA in TX Scheduling
retransmission of not acked frames is done in HW (not firmware) no
need to requeue them. In corner case when retries are exhausted  BA
request is issued from mac80211 to advance RX side window.



>> >> 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.
>
> We really need TXOP handling in mac80211 anyway, no? Right now we won't
> handle frames that are too long for the TXOP, for example.
>
>>  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 :)
>
> Like I said, from what I can tell bcom is really similar, and I'd like
> to not have to re-implement all this first. mac80211 used to have a more
> push-model, which we've deviated from with the HT stuff you did, but for
> most hardware the push-model is still appropriate, so imho we should try
> to go to one even with HT and then see.

Works for me. What I stumble upon is retransmission from within TX
response  path
how this go together with context of regular TX path. Even in iwlwifi
we need to be able to kick/start the internal aggregation queue?

We've since reworked rate
> control to be able to cope with HT too, so mac80211 can have much more
> information about what's going on and should be able to make many of the
> necessary decisions.

What to remind that iwl-agn-rs update rates scale out of band meaning
TX packet doesn't bear the rate scale information. The reasoning
behind is that appropriate rate is picked up when packet is ready to
go on the air and not when it's somewhere deep in the queue.
Otherwise it's regular multiretry algorithm.

Tomas