From owner-freebsd-net@FreeBSD.ORG Mon Oct 21 16:41:02 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 CF01A1DA for ; Mon, 21 Oct 2013 16:41:02 +0000 (UTC) (envelope-from bounces+73574-866e-freebsd-net=freebsd.org@sendgrid.me) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) by mx1.freebsd.org (Postfix) with SMTP id 55F572456 for ; Mon, 21 Oct 2013 16:41:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpapi; bh=YAwzhzPJSvmB3nuYkJU9bH92cNI=; b=oivrmVhqaIxPUYOvmQ loYL/8A67W4vVoBUs/Gz/M+3sgh8bfHtV64VGTTdwsKadvkTOKZQwko5sp8Zg9Ir CTZNC65zwxol5dbHDW7BdHau58h5fvZIvqorxTyfK9jpQW/HWKv+e6syAYvelz9h dI12Efoimfq+ovThfnPZB5Owk= Received: by filter-173.sjc1.sendgrid.net with SMTP id filter-173.20385.5265591C2 Mon, 21 Oct 2013 16:41:00 +0000 (GMT) Received: from mail.tarsnap.com (unknown [10.60.208.13]) by mi23 (SG) with ESMTP id 141dbe41701.621.5f90c2 for ; Mon, 21 Oct 2013 16:41:00 +0000 (UTC) Received: (qmail 15764 invoked from network); 21 Oct 2013 16:40:59 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 21 Oct 2013 16:40:59 -0000 Received: (qmail 79968 invoked from network); 21 Oct 2013 16:39:46 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 21 Oct 2013 16:39:46 -0000 Message-ID: <526558D2.3010505@freebsd.org> Date: Mon, 21 Oct 2013 09:39:46 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Andre Oppermann , 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> In-Reply-To: <5265450C.1060601@freebsd.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SG-EID: ISGKkmHlRE12gnWy0TjFyGQSFR1WnpjQdICm3qu6YxGf5pR9AmGV/QFF/MWIo0qUAkcm2F9VWiGcDB9KU8Q7kK0NtthMy+EzcQzHKBg38K6Xuia5KOw/MujnwFGQvvsGxapLk7iXrAAC/nAsoVHiNW9h6ZZICYpiJgQdZj6AEUM= 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: Mon, 21 Oct 2013 16:41:02 -0000 On 10/21/13 08:15, Andre Oppermann wrote: > On 21.10.2013 03:42, Colin Percival wrote: >> I can't find any changes in netfront.c or tcp_lro.c to explain why 9.1 and >> 9.2 are behaving differently -- anyone have any ideas? > > The last time I looked our soft-LRO had a few remaining issues. One of > them was that in certain situations reordering may happen with segments > that can't be aggregated into a LRO state. The other was that the driver > is responsible to manage the flushing of LRO states that haven't seen > updates in some time. It looks like the netfront driver flushes LRO every time it finishes reading packets -- if anything, it's too aggressive: /* * Flush any outstanding LRO work */ while (!SLIST_EMPTY(&lro->lro_active)) { queued = SLIST_FIRST(&lro->lro_active); SLIST_REMOVE_HEAD(&lro->lro_active, next); tcp_lro_flush(lro, queued); } So unless that code is broken somehow (it looks reasonable to me) I don't think it's a problem of data getting stuck in soft-LRO. Looking at the TCP stack on the other hand confuses me -- I see code which seems to be saying that we can delay-ACK any time that we're receiving data and don't have a delayed ACK already pending, without any regard for the fact that we might be receiving 2+ MSS at once... am I missing something here? -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid