Re: TCP performance regression

[Sujith Manoharan <sujith@msujith.org>]

Eric Dumazet wrote:
> Hmm... apparently ath9k uses :
> 
> #define ATH_AMPDU_LIMIT_MAX        (64 * 1024 - 1)

This is the maximum AMPDU size, specified in the
802.11 standard.

> And mentions a 4ms time frame :
> 
> max_4ms_framelen = ATH_AMPDU_LIMIT_MAX;

The 4ms limitation is a FCC limitation and is used
for regulatory compliance.

> So prior to "tcp: TSQ can use a dynamic limit", the ~128KB bytes TCP
> could queue per TCP socket on qdisc/NIC would happen to please ath9k

Ok.

> ath9k can set rts_aggr_limit to 8*1024 :
> 
>  if (AR_SREV_9160_10_OR_LATER(ah) || AR_SREV_9100(ah))
>   pCap->rts_aggr_limit = ATH_AMPDU_LIMIT_MAX; 
>  else
>   pCap->rts_aggr_limit = (8 * 1024);

The RTS limit is required for some old chips which had HW bugs and
the above code is a workaround.

> A timer would be definitely needed, and it should be rather small (1 or
> 2 ms)
> 
> If TCP socket is application limited, it seems ath9k can delay the last
> block by a too long time.

I am not really clear on how this regression can be fixed in the driver
since the majority of the transmission/aggregation logic is present in the
TX completion path.

Sujith