From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1fGT-00064W-H0 for qemu-devel@nongnu.org; Tue, 13 Apr 2010 08:30:49 -0400 Received: from [140.186.70.92] (port=54047 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1fGN-00061p-Be for qemu-devel@nongnu.org; Tue, 13 Apr 2010 08:30:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1fGL-0002xp-Li for qemu-devel@nongnu.org; Tue, 13 Apr 2010 08:30:43 -0400 Received: from thoth.sbs.de ([192.35.17.2]:17484) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1fGK-0002xF-VD for qemu-devel@nongnu.org; Tue, 13 Apr 2010 08:30:41 -0400 Message-ID: <4BC463EA.8000201@siemens.com> Date: Tue, 13 Apr 2010 14:30:34 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] How to lock-up your tap-based VM network References: <4BC34D95.7050804@siemens.com> <201004122107.19425.paul@codesourcery.com> <20100412214947.GC6148@shareable.org> <201004130020.13764.paul@codesourcery.com> In-Reply-To: <201004130020.13764.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Mark McLoughlin , "qemu-devel@nongnu.org" , Herbert Xu Paul Brook wrote: >> 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. It's not the bridge, I think it's limited to the tun driver as bridge participant and how it is configured/used by QEMU. > > 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. [ CC'ing some people who should have been involved in establishing the TX mitigation for tap devices. Full thread under http://thread.gmane.org/gmane.comp.emulators.qemu/67809 ] Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux