From: Eric Dumazet <eric.dumazet@gmail.com>
To: Haiyang Zhang <haiyangz@microsoft.com>
Cc: KY Srinivasan <kys@microsoft.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devel@linuxdriverproject.org" <devel@linuxdriverproject.org>
Subject: RE: [PATCH 1/1] net/hyperv: Fix the code handling tx busy
Date: Mon, 19 Mar 2012 11:23:55 -0700 [thread overview]
Message-ID: <1332181435.9397.42.camel@edumazet-glaptop> (raw)
In-Reply-To: <A1F3067C9B68744AA19F6802BAB8FFDC0DCEA84D@TK5EX14MBXC223.redmond.corp.microsoft.com>
On Mon, 2012-03-19 at 17:46 +0000, Haiyang Zhang wrote:
> We actually stop queue when the ring buffer is busy, see the code in netvsc.c
Then you dont need NETDEV_TX_BUSY at all.
When you used whole tx slots, you stop the queue, so start_xmit() wont
be called (and you wont recover from this useless call with
NETDEV_TX_BUSY)
>
> > Try this on a machine with one CPU, I am pretty sure this can trigger
> > complete freezes.
>
> I have tested with one CPU. After NETDEV_TX_BUSY is returned, the Linux
> guest OS continues to respond without any problem.
Problem is you might have used several billions cycles/instructions
without notice. Thats a busy loop and you assume consumer can empty som
tx slots while you're busy looping. Thats pretty lazy.
This path is actually hard to test. In fact most of the time its
probably never hit at all.
Some NETDEV_TX_BUSY bugs are in the code since ages and nobody
complained. Thats not a reason to add new ones.
See recents commits on this subject : Bug never triggered but it was
here fir sure.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=b8fbaef586176f6abe0eb7887ddae66e99898b79
next prev parent reply other threads:[~2012-03-19 18:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-19 17:02 [PATCH 0/1] net/hyperv: Fix the code handling tx busy Haiyang Zhang
2012-03-19 17:02 ` [PATCH 1/1] " Haiyang Zhang
2012-03-19 17:11 ` Eric Dumazet
2012-03-19 17:46 ` Haiyang Zhang
2012-03-19 18:23 ` Eric Dumazet [this message]
2012-03-19 17:48 ` Stephen Hemminger
2012-03-19 17:50 ` Haiyang Zhang
2012-03-19 18:30 ` Eric Dumazet
2012-03-19 19:17 ` Haiyang Zhang
2012-03-19 20:46 ` Eric Dumazet
2012-03-19 20:50 ` Haiyang Zhang
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=1332181435.9397.42.camel@edumazet-glaptop \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=devel@linuxdriverproject.org \
--cc=haiyangz@microsoft.com \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.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