Re: [PATCH v2 08/12] ath9k: fix aggregate size limit based on queue TXOP limit

[Felix Fietkau <nbd@openwrt.org>]

On 2012-07-16 10:15 AM, Sujith Manoharan wrote:
> Felix Fietkau wrote:
>> Yes, but ath9k only has global queue settings, not per-vif ones, so I'm
>> not sure what can be done about the issue of overwriting queue settings.
> 
> Yeah, me neither.
> 
>> Either way, it's important for the aggregation limit to be in sync with
>> the hardware queue TXOP limit, so I believe this patch is correct.
> 
> Except that earlier it was a global, static table. I am curious, which part
> of the standard deals with limiting AMPDU size based on txop ? I searched a bit
> and got lost.
The standard does not say anything specifically about A-MPDU, but it
does say this:

When the TXOP limit is nonzero, a STA shall fragment an individually
addressed MSDU so that the transmission of the first MPDU of the TXOP
does not cause the TXOP limit to be exceeded at the PHY rate selected
for the initial transmission attempt of that MPDU. The TXOP limit may be
exceeded, when using a lower PHY rate than selected for the initial
transmission attempt of the first MPDU, for a retransmission of an MPDU,
for the initial transmission of an MPDU if any previous MPDU in the
current MSDU has been retransmitted, or for group addressed MSDUs. When
the TXOP limit is exceeded due to the retransmission of an MPDU at a
reduced PHY rate, the STA shall not transmit more than one MPDU in the TXOP.

Since 3 ms for VI (default) is still a lot and this queue is meant to
have lower latency compared to BE/BK, I decided to not add any special
rules to treat retransmissions differently.
I'm not sure if it's absolutely required to reduce the A-MPDU
transmission duration here, but even if it isn't, it's still a good idea
for reducing latency, and it does look like it reduces the amount of
retransmissions under load.

The only other queue that has a TXOP limit set by default is the VO
queue, but that one can be ignored since it doesn't do aggregation.

- Felix