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
next prev parent 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).