qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Ingo Krabbe <ikrabbe.ask@gmail.com>
Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
	jasowang@redhat.com
Subject: Re: [Qemu-devel] TCP Segementation Offloading
Date: Thu, 5 May 2016 18:42:03 +0100	[thread overview]
Message-ID: <20160505174203.GC14181@stefanha-x1.localdomain> (raw)
In-Reply-To: <404102019afadcf28f8dcb958fcbf617@yourdomain.dom>

[-- Attachment #1: Type: text/plain, Size: 2453 bytes --]

On Sun, May 01, 2016 at 02:31:57PM +0200, Ingo Krabbe wrote:
> Good Mayday Qemu Developers,
> 
> 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 environments.
> 
> 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" with ethtool, for the guest driver if I use a hardware emulation, such as e1000 and/or "tso off gso off" for the host driver and/or for the bridge adapter, if I use the virtio driver, as otherwise you experience (sometimes?) performance 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 checksums.
> 
> There is a tso related bug on launchpad, but the context of this bug is too narrow, for the generality of the problem.
> 
> 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).
> 
> 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 this topic in the past or is there any planned/ongoing work todo on the qemu drivers?
> 
> Most problem reports found relate to deprecated Centos6 qemu-kvm packages.
> 
> 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 whom should I sent my reports about this topic?).

I have CCed Michael Tsirkin and Jason Wang.  They do most of the
virtio-net development.

> 
> Regards,
> 
> Ingo Krabbe
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2016-05-05 17:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-01 12:31 [Qemu-devel] TCP Segementation Offloading Ingo Krabbe
2016-05-05 17:42 ` Stefan Hajnoczi [this message]
2016-05-06  4:34   ` Ingo Krabbe
2016-05-06 16:28     ` Stefan Hajnoczi
2016-05-09 12:12       ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160505174203.GC14181@stefanha-x1.localdomain \
    --to=stefanha@gmail.com \
    --cc=ikrabbe.ask@gmail.com \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).