[rt2x00-users] [RFC] rt2x00: Implement tx mpdu aggregation

[Ivo Van Doorn]

On Mon, Jun 14, 2010 at 4:08 PM, Helmut Schaa
<helmut.schaa at googlemail.com> wrote:
> Resending with not only Felix CC'ed ;)
>
> On Mon, Jun 14, 2010 at 4:06 PM, Helmut Schaa <helmut.schaa at googlemail.com>
> wrote:
>>
>> On Sun, Jun 13, 2010 at 1:44 PM, Felix Fietkau <nbd at openwrt.org> wrote:
>>>
>>> On 2010-06-11 10:59 AM, Helmut Schaa wrote:
>>> > Ok, rechecked today. We really get one tx status (from TX_STA_FIFO) per
>>> > MPDU
>>> > (not per AMPDU) and hence the tx status is on a MPDU base and not on an
>>> > AMPDU
>>> > base.
>>> >
>>> > Since the aggregation is completely done in hw including resending of
>>> > failed
>>> > MPDUs we don't even know which frames were aggregated together. We only
>>> > know
>>> > if a MPDU was aggregated or not.
>>> >
>>> > So, we basically tell the device only "this frame is eligible" for an
>>> > AMPDU
>>> > and the hw will decide on everything else.
>>> >
>>> > So, the only possibility to report the AMPDU status is to report every
>>> > single
>>> > MPDU as AMPDU if len 1.
>>> >
>>> > Hope thie clarifies my intentions ;)
>>> >
>>> > I'm going to update the comment in the tx status processing to be more
>>> > precise.
>>> It would be nice if we could find some way of getting the real AMPDU
>>> length, because minstrel_ht does take it into account for figuring out
>>> the best tx rate, and it does make a difference.
>>
>> Thanks for pointing that out Felix. That would be nice indeed. However we
>> would have
>> to somehow aggregate subsequent tx status reports according to some
>> aggregation
>> counters for example before sending the tx status to mac80211.
>>
>> I'd like to stick to the ampdu_len=1 solution _for now_ as it will at
>> least allow us to
>> enable aggregation. I'll add a TODO comment there to not forget about it.
>>
>> Is that ok for everyone?

Sounds good to me. :)
As long as the current code works, I have no objections of adding
TODO's for improving performance.

Ivo