From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42167) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ayNIK-00022T-AZ for qemu-devel@nongnu.org; Thu, 05 May 2016 13:42:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ayNI8-0006R4-D2 for qemu-devel@nongnu.org; Thu, 05 May 2016 13:42:30 -0400 Received: from mail-wm0-x232.google.com ([2a00:1450:400c:c09::232]:36980) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ayNI6-0006Fs-MX for qemu-devel@nongnu.org; Thu, 05 May 2016 13:42:24 -0400 Received: by mail-wm0-x232.google.com with SMTP id a17so39756914wme.0 for ; Thu, 05 May 2016 10:42:08 -0700 (PDT) Date: Thu, 5 May 2016 18:42:03 +0100 From: Stefan Hajnoczi Message-ID: <20160505174203.GC14181@stefanha-x1.localdomain> References: <404102019afadcf28f8dcb958fcbf617@yourdomain.dom> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+nBD6E3TurpgldQp" Content-Disposition: inline In-Reply-To: <404102019afadcf28f8dcb958fcbf617@yourdomain.dom> Subject: Re: [Qemu-devel] TCP Segementation Offloading List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ingo Krabbe Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" , jasowang@redhat.com --+nBD6E3TurpgldQp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 01, 2016 at 02:31:57PM +0200, Ingo Krabbe wrote: > Good Mayday Qemu Developers, >=20 > today I tried to find a reference to a networking problem, that seems to = be of quite general nature: TCP Segmentation Offloading (TSO) in virtual en= vironments. >=20 > When I setup TAP network adapter for a virtual machine and put it into a = host bridge, the known best practice is to manually set "tso off gso off" w= ith ethtool, for the guest driver if I use a hardware emulation, such as e1= 000 and/or "tso off gso off" for the host driver and/or for the bridge adap= ter, if I use the virtio driver, as otherwise you experience (sometimes?) p= erformance problems or even lost packages. I can't parse this sentence. In what cases do you think it's a "known best practice" to disable tso and gso? Maybe a table would be a clearer way to communicate this. Can you provide a link to the source claiming tso and gso should be disabled? > I haven't found a complete analysis of the background of these problems, = but there seem to be some effects on MTU based fragmentation and UDP checks= ums. >=20 > There is a tso related bug on launchpad, but the context of this bug is t= oo narrow, for the generality of the problem. >=20 > Also it seems that there is a problem in LXC contexts too (I found such a= reference, without detailed description in a Post about Xen setup). >=20 > My question now is: Is there a bug in the driver code and shouldn't this = be documented somewhere in wiki.qemu.org? Where there developments about th= is topic in the past or is there any planned/ongoing work todo on the qemu = drivers? >=20 > Most problem reports found relate to deprecated Centos6 qemu-kvm packages. >=20 > In our company we have similar or even worse problems with Centos7 hosts = and guest machines. Have haven't explained what problem you are experiencing. If you want help with your setup please include your QEMU command-line (ps aux | grep qemu), the traffic pattern (ideally how to reproduce it with a benchmarking tool), and what observation you are making (e.g. netstat counters showing dropped packets). > I'm going to analyze these problems next week anyway and I woud be happy = to share my observation with you. (Where can I register for the wiki, or wh= om should I sent my reports about this topic?). I have CCed Michael Tsirkin and Jason Wang. They do most of the virtio-net development. >=20 > Regards, >=20 > Ingo Krabbe >=20 >=20 --+nBD6E3TurpgldQp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXK4XqAAoJEJykq7OBq3PISDcIAL4NQFh1G/sYjdYXIaNiPb1C 34Psgg/U6N/RELTz1kJFX5PJE2S46+Q6LYBx5n3ulr7vNPMLIZPD7rXsdiM8zboF iN67YXwF4ChnFah9KmiS0/27vrBEQeOT4f0la5q+utTEudmDh/irkFCcRuZmwBnH rEtTPBBb8323zT3BHglD6QnP6vYMsK6+GO3GXpzZCTUhgIKTRx7ExoYX49fK/Kal ulywi1Y4JIKIKJ4NbqKnQhhrmU3twmThtv72xi3087t234RBus90nr+SO3dwJkAJ c9ocRFb1n7j04wOTg3y2sNwzzTkipHyBweGwsMmbkFoLHWUTUxiUHCLSEaSq1uk= =CpkN -----END PGP SIGNATURE----- --+nBD6E3TurpgldQp--