shithub: riscv

Download patch

ref: 21f97338f86b9aa4a2995ddc7bbe539efadfab70
parent: e611879eab9ad99ea6fa1f51529c4c85e679dad2
author: cinap_lenrek <cinap_lenrek@felloff.net>
date: Thu May 14 17:09:12 EDT 2015

tcp: fix loopback slowness issue / set tcb->mss for incoming connections (thanks David du Colombier)

David du Colombier wrote:
> The slowness issue only appears on the loopback, because
> it provides a 16384 MTU.
>
> There is an old bug in the Plan 9 TCP stack, were the TCP
> MSS doesn't take account the MTU for incoming connections.
>
> I originally fixed this issue in January 2015 for the Plan 9
> port on Google Compute Engine. On GCE, there is an unusual
> 1460 MTU.
>
> The Plan 9 TCP stack defines a default 1460 MSS corresponding
> to a 1500 MTU. Then, the MSS is fixed according to the MTU
> for outgoing connections, but not incoming connections.
>
> On GCE, this issue leads to IP fragmentation, but GCE didn't
> handle IP fragmentation properly, so the connections
> were dropped.
>
> On the loopback medium, I suppose this is the opposite issue.
> Since the TCP stack didn't fix the MSS in the incoming
> connection, the programs sent multiple small 1500 bytes
> IP packets instead of large 16384 IP packets, but I don't
> know why it leads to such a slowdown.

--- a/sys/src/9/ip/tcp.c

+++ b/sys/src/9/ip/tcp.c

@@ -1770,11 +1770,13 @@

 	tcb->flgcnt = 0;

 	tcb->flags |= SYNACK;

+	/* set desired mss and scale */

+	tcb->mss = tcpmtu(s->p, s->laddr, s->ipversion, &tcb->scale);

+

 	/* our sending max segment size cannot be bigger than what he asked for */

-	if(lp->mss != 0 && lp->mss < tcb->mss) {

+	if(lp->mss != 0 && lp->mss < tcb->mss)

 		tcb->mss = lp->mss;

-		tpriv->stats[Mss] = tcb->mss;

-	}

+	tpriv->stats[Mss] = tcb->mss;

 	/* window scaling */

 	tcpsetscale(new, tcb, lp->rcvscale, lp->sndscale);