Greetings all, There seems to be an anomoly in tcp_tso_should_defer which causes minor problems with TCP Westwood, and major problems with FAST TCP.
The check
chunk /= sysctl_tcp_tso_win_divisor;
if (limit >= chunk)
return 0;
limits the number of bytes outstanding to
cwnd * (1 - 1/tso_win_divisor)
instead of limiting it to cwnd. That is fine for most protocols,
since they increase their CWND to compensate this. However, FAST TCP
(and Westwood) base their CWND on the number of packets in flight. By
reducing CWND to the current PIF, the new PIF is further restricted.
This effect is most noticable when the bandwidth-delay product is
large; my experiments are at 1Gbps with a 29ms RTT.
The reason for tcp_tso_should_defer appears to be to allow enough
space for a full-sized 64k socket buffer to be created. I propose
checking that condition explicitly, as in the attached patch,
reproduced below, relative to 2.6.15.3.
I welcome people's comments on this suggestion.
Cheers,
Lachlan Andrew, FAST TCP developer.
--- net/ipv4/tcp_output.c.orig 2006-03-07 17:18:09.000000000 -0800
+++ net/ipv4/tcp_output.c 2006-03-07 17:19:21.000000000 -0800
@@ -966,6 +966,10 @@ static int tcp_tso_should_defer(struct s
limit = min(send_win, cong_win);
+ /* If this skb plus a full-sized TSO skb can be sent, do it */
+ if (limit > 2 * 65536)
+ return 0;
+
if (sysctl_tcp_tso_win_divisor) {
u32 chunk = min(tp->snd_wnd, tp->snd_cwnd * tp->mss_cache);
(My mailer may have replaced tabs with spaces, so apply the patch in
the attachment, not the above.)
--
Lachlan Andrew Dept of Computer Science, Caltech
Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603
TSO-patch-lachlan
Description: Binary data
