From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1Svc-0007Z5-DH for qemu-devel@nongnu.org; Mon, 12 Apr 2010 19:20:28 -0400 Received: from [140.186.70.92] (port=53594 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1Svb-0007YC-6n for qemu-devel@nongnu.org; Mon, 12 Apr 2010 19:20:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1SvZ-0006li-AU for qemu-devel@nongnu.org; Mon, 12 Apr 2010 19:20:27 -0400 Received: from mx20.gnu.org ([199.232.41.8]:62899) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1SvZ-0006le-6L for qemu-devel@nongnu.org; Mon, 12 Apr 2010 19:20:25 -0400 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1O1SvY-0004yB-MD for qemu-devel@nongnu.org; Mon, 12 Apr 2010 19:20:24 -0400 From: Paul Brook Subject: Re: [Qemu-devel] How to lock-up your tap-based VM network Date: Tue, 13 Apr 2010 00:20:13 +0100 References: <4BC34D95.7050804@siemens.com> <201004122107.19425.paul@codesourcery.com> <20100412214947.GC6148@shareable.org> In-Reply-To: <20100412214947.GC6148@shareable.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004130020.13764.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Jan Kiszka > But anyway, this flow control mechanism is buggy - what if instead of > an interface down, you just have a *slow* guest? That should not push > back so much that it makes other guests networking with each other > slow down. The OP described multiple guests connected via a host bridge. In this case it is entirely the host's responsibility to arbitrate between multiple guests. If one interface can block the bridge simply by failing to respond in a timely manner then this is a serious bug or misconfiguration of your host bridge. The reason tap_send exists is because slirp does not implement TCP flow control properly. Instead it relies on the can_send hook to only avoid dropped packets. Using this in the tap code is debatable. My guess is that this is a hack to workaround guest network stacks that expect throughput to be limited by line speed (which is a virtual environment is effectively infinite), have poor higher level flow control, and react badly to packet loss. Paul