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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
