From: Krishna Kumar <krkumar2@in.ibm.com>
To: davem@davemloft.net
Cc: herbert@gondor.apana.org.au, mst@redhat.com,
netdev@vger.kernel.org, rusty@rustcorp.com.au,
Krishna Kumar <krkumar2@in.ibm.com>,
sri@us.ibm.com
Subject: Re: [RFC PATCH] Regression in linux 2.6.32 virtio_net seen with vhost-net
Date: Thu, 17 Dec 2009 16:50:34 +0530 [thread overview]
Message-ID: <20091217112034.9937.48474.sendpatchset@krkumar2.in.ibm.com> (raw)
> On Thu, Dec 17, 2009, Krishna Kumar2/India/IBM@IBMIN wrote on
>
> Subject: Re: [RFC PATCH] Regression in linux 2.6.32 virtio_net seen with vhost-net
>
> > >> I think sch_direct_xmit() is not even calling dev_hard_start_xmit() as
> > >> the tx queue is stopped
> > >> and does a dev_requeue_skb() and returns NETDEV_TX_BUSY.
> > >
> > > Yes but if the queue was stopped then we shouldn't even get into
> > > sch_direct_xmit.
> > I don't see any checks for txq_stopped in the callers of
> sch_direct_xmit() :
> > __dev_xmit_skb() and qdisc_restart(). Both these routines get the txq
> > and call
> > sch_direct_xmit() which checks if tx queue is stopped or frozen.
> >
> > Am i missing something?
>
> Yes - dequeue_skb.
>
> The final skb, before the queue was stopped, is transmitted by
> the driver. The next time sch_direct_xmit is called, it gets a
> skb and finds the device is stopped and requeue's the skb. For
> all subsequent xmits, dequeue_skb returns NULL (and the other
> caller - __dev_xmit_skb can never be called since qdisc_qlen is
> true) and thus requeue's will not happen. This also means that
> the number of requeues you see (eg 283K in one run) is the number
> of times the queue was stopped and restarted. So it looks like
> driver either:
>
> 1. didn't stop the queue when xmiting a packet successfully (the
> condition being that it would not be possible to xmit the
> next skb). But this doesn't seem to be the case.
> 2. wrongly restarted the queue. Possible - since a few places
> use both the start & wake queue api's.
[ Resending, since I sent to wrong id last time - sorry for
some duplicates ]
On a (slightly) related note, qdisc_restart() has this code:
/* Dequeue packet */
skb = dequeue_skb(q);
if (unlikely(!skb))
return 0;
When a txq is stopped, all subsequent dev_queue_xmits will
execute this path, pass the "unlikely" code, and return. Is
it reasonable to remove "unlikely" in both dequeue_skb and
qdisc_restart, if so patch inlined below:
thanks,
- KK
From: Krishna Kumar <krkumar2@in.ibm.com>
1. Remove two unlikely checks since stopped queue's will result
int getting a NULL skb.
2. Remove an extra space after unlikely check.
Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
---
net/sched/sch_generic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff -ruNp org/net/sched/sch_generic.c new/net/sched/sch_generic.c
--- org/net/sched/sch_generic.c 2009-12-17 16:29:59.000000000 +0530
+++ new/net/sched/sch_generic.c 2009-12-17 16:30:55.000000000 +0530
@@ -51,7 +51,7 @@ static inline struct sk_buff *dequeue_sk
{
struct sk_buff *skb = q->gso_skb;
- if (unlikely(skb)) {
+ if (skb) {
struct net_device *dev = qdisc_dev(q);
struct netdev_queue *txq;
@@ -134,7 +134,7 @@ int sch_direct_xmit(struct sk_buff *skb,
ret = handle_dev_cpu_collision(skb, txq, q);
} else {
/* Driver returned NETDEV_TX_BUSY - requeue skb */
- if (unlikely (ret != NETDEV_TX_BUSY && net_ratelimit()))
+ if (unlikely(ret != NETDEV_TX_BUSY && net_ratelimit()))
printk(KERN_WARNING "BUG %s code %d qlen %d\n",
dev->name, ret, q->q.qlen);
@@ -176,7 +176,7 @@ static inline int qdisc_restart(struct Q
/* Dequeue packet */
skb = dequeue_skb(q);
- if (unlikely(!skb))
+ if (!skb)
return 0;
root_lock = qdisc_lock(q);
next reply other threads:[~2009-12-17 11:20 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-17 11:20 Krishna Kumar [this message]
2009-12-17 19:28 ` [RFC PATCH] Regression in linux 2.6.32 virtio_net seen with vhost-net Jarek Poplawski
[not found] <20091217111219.9809.27432.sendpatchset@krkumar2.in.ibm.com>
[not found] ` <20091217123153.GA31131@gondor.apana.org.au>
2009-12-17 12:56 ` Krishna Kumar2
2009-12-17 13:40 ` Herbert Xu
2009-12-17 13:56 ` Krishna Kumar2
-- strict thread matches above, loose matches on Subject: below --
2009-12-08 22:50 Sridhar Samudrala
2009-12-13 12:25 ` Herbert Xu
2009-12-13 23:40 ` Michael S. Tsirkin
2009-12-15 14:42 ` Herbert Xu
2009-12-15 16:26 ` Sridhar Samudrala
2009-12-16 1:21 ` Herbert Xu
2009-12-15 23:32 ` Michael S. Tsirkin
2009-12-16 1:58 ` Herbert Xu
2009-12-16 4:37 ` Rusty Russell
2009-12-16 10:37 ` Michael S. Tsirkin
2009-12-16 2:41 ` Rusty Russell
2009-12-16 2:53 ` Herbert Xu
2009-12-16 12:45 ` Rusty Russell
2009-12-16 13:22 ` Michael S. Tsirkin
2009-12-16 13:35 ` Herbert Xu
2009-12-16 13:38 ` Michael S. Tsirkin
2009-12-16 13:48 ` Herbert Xu
2009-12-17 2:02 ` Rusty Russell
2009-12-17 9:25 ` Michael S. Tsirkin
2009-12-18 1:55 ` Rusty Russell
2009-12-16 13:30 ` Herbert Xu
2009-12-17 1:43 ` Sridhar Samudrala
2009-12-17 3:12 ` Herbert Xu
2009-12-17 5:02 ` Sridhar Samudrala
2009-12-17 3:15 ` Herbert Xu
2009-12-17 5:05 ` Sridhar Samudrala
2009-12-17 6:28 ` Herbert Xu
2009-12-17 6:45 ` Sridhar Samudrala
2009-12-17 10:03 ` Krishna Kumar2
2009-12-17 11:27 ` Jarek Poplawski
2009-12-17 11:45 ` Herbert Xu
2009-12-17 11:49 ` Herbert Xu
2009-12-17 12:08 ` Herbert Xu
2009-12-17 12:27 ` Krishna Kumar2
2009-12-17 12:42 ` Jarek Poplawski
2009-12-17 12:56 ` Herbert Xu
2009-12-17 13:22 ` Krishna Kumar2
2009-12-17 13:04 ` Krishna Kumar2
2009-12-17 13:44 ` Herbert Xu
2009-12-17 14:35 ` Krishna Kumar2
2009-12-17 14:36 ` Herbert Xu
2009-12-17 21:50 ` Sridhar Samudrala
2009-12-17 22:28 ` Sridhar Samudrala
2009-12-17 22:41 ` Jarek Poplawski
2009-12-18 13:46 ` Krishna Kumar2
2009-12-18 19:13 ` Sridhar Samudrala
2009-12-17 11:59 ` Krishna Kumar2
2009-12-17 12:19 ` Jarek Poplawski
2009-12-17 11:56 ` Krishna Kumar2
2009-12-17 13:17 ` Jarek Poplawski
2009-12-17 14:10 ` Krishna Kumar2
2009-12-17 14:16 ` Herbert Xu
2009-12-16 17:42 ` Sridhar Samudrala
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=20091217112034.9937.48474.sendpatchset@krkumar2.in.ibm.com \
--to=krkumar2@in.ibm.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=sri@us.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).