kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Wright <chrisw@sous-sol.org>
To: Tom Lendacky <tahm@linux.vnet.ibm.com>
Cc: Chris Wright <chrisw@sous-sol.org>, Avi Kivity <avi@redhat.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	rek2 <rek2@binaryfreedom.info>,
	kvm@vger.kernel.org, markmc@redhat.com
Subject: Re: network shutdown under heavy load
Date: Tue, 19 Jan 2010 15:57:53 -0800	[thread overview]
Message-ID: <20100119235753.GI3204@sequoia.sous-sol.org> (raw)
In-Reply-To: <201001191529.01519.tahm@linux.vnet.ibm.com>

* Tom Lendacky (tahm@linux.vnet.ibm.com) wrote:
> On Wednesday 13 January 2010 03:52:28 pm Chris Wright wrote:
> > (Mark cc'd, sound familiar?)
> > 
> > * Tom Lendacky (tahm@linux.vnet.ibm.com) wrote:
> > > On Sunday 10 January 2010 06:38:54 am Avi Kivity wrote:
> > > > On 01/10/2010 02:35 PM, Herbert Xu wrote:
> > > > > On Sun, Jan 10, 2010 at 02:30:12PM +0200, Avi Kivity wrote:
> > > > >> This isn't in 2.6.27.y.  Herbert, can you send it there?
> > > > >
> > > > > It appears that now that TX is fixed we have a similar problem
> > > > > with RX.  Once I figure that one out I'll send them together.
> > >
> > > I've been experiencing the network shutdown issue also.  I've been
> > > running netperf tests across 10GbE adapters with Qemu 0.12.1.2, RHEL5.4
> > > guests and 2.6.32 kernel (from kvm.git) guests.  I instrumented Qemu to
> > > print out some network statistics.  It appears that at some point in the
> > > netperf test the receiving guest ends up having the 10GbE device
> > > "receive_disabled" variable in its VLANClientState structure stuck at 1. 
> > > From looking at the code it appears that the virtio-net driver in the
> > > guest should cause qemu_flush_queued_packets in net.c to eventually run
> > > and clear the "receive_disabled" variable but it's not happening.  I
> > > don't seem to have these issues when I have a lot of debug settings
> > > active in the guest kernel which results in very low/poor network
> > > performance - maybe some kind of race condition?
> 
> Ok, here's an update. After realizing that none of the ethtool offload options
> were enabled in my guest, I found that I needed to be using the -netdev option
> on the qemu command line.  Once I did that, some ethtool offload options were 
> enabled and the deadlock did not appear when I did networking between guests 
> on different machines.  However, the deadlock did appear when I did networking
> between guests on the same machine.

What does your full command line look like?  And when the networking
stops does your same receive_disabled hack make things work?

thanks,
-chris

  reply	other threads:[~2010-01-19 23:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-14 15:49 network shutdown under heavy load rek2
2009-12-16 12:17 ` Avi Kivity
2009-12-16 13:19   ` Herbert Xu
2009-12-17 18:15     ` rek2
2009-12-18  1:27       ` Herbert Xu
2009-12-21 16:39         ` rek2
2010-01-07 17:02           ` rek2
2010-01-10 12:30             ` Avi Kivity
2010-01-10 12:35               ` Herbert Xu
2010-01-10 12:38                 ` Avi Kivity
2010-01-13 19:13                   ` Tom Lendacky
2010-01-13 21:52                     ` Chris Wright
2010-01-19 21:29                       ` Tom Lendacky
2010-01-19 23:57                         ` Chris Wright [this message]
2010-01-20 15:48                           ` Tom Lendacky
2010-01-26 21:59                             ` Tom Lendacky
2010-02-09 20:03                               ` Jean-Philippe Menil
2010-02-09 20:25                                 ` Chris Wright
2010-02-09 20:46                                   ` Jean-Philippe Menil
2010-02-10  7:53                                     ` Jean-Philippe Menil

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=20100119235753.GI3204@sequoia.sous-sol.org \
    --to=chrisw@sous-sol.org \
    --cc=avi@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=kvm@vger.kernel.org \
    --cc=markmc@redhat.com \
    --cc=rek2@binaryfreedom.info \
    --cc=tahm@linux.vnet.ibm.com \
    /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).