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

[Helmut Schaa]

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?
>
> Helmut
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/attachments/20100614/5391336d/attachment.html>