[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Nov 2013 13:49:27 +0530
From: Sujith Manoharan <sujith@...jith.org>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: netdev@...r.kernel.org
Subject: Re: TCP performance regression
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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists