From patchwork Tue Apr 17 14:10:58 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jessica Clarke X-Patchwork-Id: 10345191 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id C39BE60216 for ; Tue, 17 Apr 2018 14:13:26 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BD8F527FA3 for ; Tue, 17 Apr 2018 14:13:26 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B2168283CB; Tue, 17 Apr 2018 14:13:26 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 0ED4F27FA3 for ; Tue, 17 Apr 2018 14:13:25 +0000 (UTC) Received: from localhost ([::1]:41100 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f8RMK-0003yW-Vs for patchwork-qemu-devel@patchwork.kernel.org; Tue, 17 Apr 2018 10:13:25 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38178) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f8RKI-0002x4-AW for qemu-devel@nongnu.org; Tue, 17 Apr 2018 10:11:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f8RKC-00050w-FG for qemu-devel@nongnu.org; Tue, 17 Apr 2018 10:11:18 -0400 Received: from mail-wr0-x244.google.com ([2a00:1450:400c:c0c::244]:35589) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f8RKC-0004zm-75 for qemu-devel@nongnu.org; Tue, 17 Apr 2018 10:11:12 -0400 Received: by mail-wr0-x244.google.com with SMTP id w3so19339662wrg.2 for ; Tue, 17 Apr 2018 07:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jrtc27.com; s=google; h=from:to:cc:subject:date:message-id; bh=j2IuPBcXnCOjUDBn4GFvwIVtVzlTLEXaomNfR6Mqk8U=; b=Iz1/oL1oKWfQNN253SLpM5nZ5INPRoWPRiWv9GlfWD1wGVKdofaV0kgERg5szxeXMg AvATKeZ/lsr9jI+zKIv+xyPiEVqzx1S2m/pqOwcvHKel/4VLKkEcTfR516T3+5e8WzTv jEcMJTMIg/ymvTGLcSOcCSGLV8qiTyqbMgjNU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=j2IuPBcXnCOjUDBn4GFvwIVtVzlTLEXaomNfR6Mqk8U=; b=YdjwfLQIBcF6CK60j/Guo761CwWuJ/RvwTpA05iyiat353cb9U9sphzHXaPZL0svLs Dzze085Ye8IUP225mxHDCob/Tc8eCshVZlLOP1PZr1AJJzBbMs1acAlZE16MfCGeW6LW /gu916biEVw4TI8WvdIUsi3FTYyZG5+aF+rzcnyuZBW8BiH8ZsN0eHlUXW5qaLINhoWv tR5+HymXbRBWXjw8uY+6IMid3Ewldf/QrOPwQ0dFHeYkx9QJy+J7UnJAKl0BOk0XL3Iz mRZxfS7KA5UuLN0m5TyCiJGWn1em7hldRJaZVvLNBMNxvcXBm3+oNv9dk1h3QH4zER5t wdRQ== X-Gm-Message-State: ALQs6tCszbE58aF2KM5RSsBiDSAYl1XjNO9PJaN/mAs4Bcmxx5W7PHa9 CBcTh/IIhjkda9cMWuJs48W1iw== X-Google-Smtp-Source: AIpwx486Yz3RRPtSiT0HCtVA2rthiONzIOvJBw3J/vonQRuWIDbMcfIhDRh2vi8FFtEEmLkoSZsCfg== X-Received: by 10.223.138.183 with SMTP id y52mr1811262wry.98.1523974270926; Tue, 17 Apr 2018 07:11:10 -0700 (PDT) Received: from Jamess-MacBook.local (host81-134-41-189.in-addr.btopenworld.com. [81.134.41.189]) by smtp.gmail.com with ESMTPSA id 4sm8124957wrz.58.2018.04.17.07.11.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Apr 2018 07:11:09 -0700 (PDT) Received: by Jamess-MacBook.local (Postfix, from userid 501) id 02E9A201A30099; Tue, 17 Apr 2018 15:11:07 +0100 (BST) From: James Clarke To: qemu-devel@nongnu.org Date: Tue, 17 Apr 2018 15:10:58 +0100 Message-Id: <20180417141058.31236-1-jrtc27@jrtc27.com> X-Mailer: git-send-email 2.17.0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c0c::244 Subject: [Qemu-devel] [PATCH] slirp: Send window updates to guest after window was closed X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Samuel Thibault , James Clarke , Jan Kiszka Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP If the receive window presented to the guest closes, slirp should send a window update once the window reopens sufficiently, rather than forcing the guest to send a window probe, which can take several seconds. Signed-off-by: James Clarke --- Hi, I encountered this whilst running a (k)FreeBSD build server for Debian. The host's upload link is over ADSL and thus rather slow, so slirp's outgoing buffer soon fills up, causing it to close its receive window. However, without this patch, slirp does not send a window update back to the guest once it starts draining its outgoing buffer and thus opening its receive window, causing the guest to remain blocked until its persist timer next fires and it sends a zero window probe. In the case of a Linux guest, this starts at ~200ms and grows exponentially, though most of the time the receive window has already opened by then and thus the unnecessary delay doesn't have too much of an effect, but the FreeBSD network stack defaults to a 5s minimum for the persist timer and thus spends the vast majority of its time not transmitting data, with the upload speed achieved around 10 KiB/s for this particular guest and link. VirtualBox, which uses slirp for its NAT networking mode, also encountered this and fixed it back in 2014 with [1], but interestingly decided to set its own delayed ACK flag and wait for its own timer to fire, rather than calling tcp_output directly. I don't know what their motivation for that decision was, but to me that seems to add an unnecessary delay of up to a few hundred ms (though that is of course still much better than 5s). I have been testing this patch for the past few days with the build server uploading its huge backlog of packages one at a time. It is now reaching 1.3 Mbit/s and networking has remained seemingly stable. Regards, James [1] https://github.com/mirror/vbox/commit/87c7aa2e8d26b989da6e85d532695f1e3b050aaa slirp/slirp.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) -- 2.17.0 diff --git a/slirp/slirp.c b/slirp/slirp.c index 1cb6b07004..238fb04115 100644 --- a/slirp/slirp.c +++ b/slirp/slirp.c @@ -676,13 +676,13 @@ void slirp_pollfds_poll(GArray *pollfds, int select_error) /* continue; */ } else { ret = sowrite(so); + if (ret > 0) { + /* Call tcp_output in case we need to send a window + * update to the guest, otherwise it will be stuck + * until it sends a window probe. */ + tcp_output(sototcpcb(so)); + } } - /* - * XXXXX If we wrote something (a lot), there - * could be a need for a window update. - * In the worst case, the remote will send - * a window probe to get things going again - */ } /*