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

I welcome people's comments on this suggestion.

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

Attachment: TSO-patch-lachlan
Description: Binary data

Reply via email to