From owner-freebsd-net@FreeBSD.ORG Tue Oct 22 08:01:22 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5115E590 for ; Tue, 22 Oct 2013 08:01:22 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9E274266D for ; Tue, 22 Oct 2013 08:01:21 +0000 (UTC) Received: (qmail 44809 invoked from network); 22 Oct 2013 08:33:11 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Oct 2013 08:33:11 -0000 Message-ID: <526630C3.4090008@freebsd.org> Date: Tue, 22 Oct 2013 10:01:07 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Colin Percival , Julian Elischer , freebsd-net@freebsd.org Subject: Re: LRO causing stretch ACK violations interacts badly with delayed ACKing References: <52605EC9.6090406@freebsd.org> <526478D0.1000601@freebsd.org> <5264869E.4000308@freebsd.org> <5265450C.1060601@freebsd.org> <526558D2.3010505@freebsd.org> <52658726.4030106@freebsd.org> <52658A79.6070705@freebsd.org> <52659569.8090301@freebsd.org> In-Reply-To: <52659569.8090301@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 08:01:22 -0000 On 21.10.2013 22:58, Colin Percival wrote: > On 10/21/13 13:11, Andre Oppermann wrote: >> On 21.10.2013 21:57, Andre Oppermann wrote: >>> This is an excellent observation! Our tcp doesn't know about LRO >>> and I prepared the mbuf header to carry information about the number >>> of merged LRO segments. That's not done yet again. However a small >>> heuristic in tcp_input looking for segment > mss should be sufficient >>> for now. Let me have a look at patching it into a suitable place. >> >> Please check out the patch below. Haven't tested it myself yet though. > > Yes, this works: >> 00:00:00.000000 IP 10.148.229.78.24405 > 176.32.98.166.443: Flags [S], seq 3220740500, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 350742 ecr 0], length 0 >> 00:00:00.000613 IP 176.32.98.166.443 > 10.148.229.78.24405: Flags [S.], seq 1783557911, ack 3220740501, win 8190, options [mss 1460,nop,wscale 6], length 0 >> 00:00:00.000657 IP 10.148.229.78.24405 > 176.32.98.166.443: Flags [.], ack 1, win 1026, length 0 >> 00:00:00.001842 IP 176.32.98.166.443 > 10.148.229.78.24405: Flags [.], ack 1, win 127, length 0 >> 00:00:00.032269 IP 10.148.229.78.24405 > 176.32.98.166.443: Flags [P.], seq 1:318, ack 1, win 1026, length 317 >> 00:00:00.033080 IP 176.32.98.166.443 > 10.148.229.78.24405: Flags [.], ack 318, win 108, length 0 >> 00:00:00.033115 IP 176.32.98.166.443 > 10.148.229.78.24405: Flags [.], seq 1:4097, ack 318, win 108, length 4096 >> 00:00:00.033129 IP 10.148.229.78.24405 > 176.32.98.166.443: Flags [.], ack 4097, win 962, length 0 > > Please commit this fix and get it merged for 10.0-RELEASE! I committed it to my staging branch pending review: http://svnweb.freebsd.org/changeset/base/256879 It should go into HEAD later this week and the MFC to 10.x then depends on re@'s take on it. -- Andre