All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	"Jamal Hadi Salim" <hadi@cyberus.ca>,
	"Stephen Hemminger" <shemminger@vyatta.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Neil Horman" <nhorman@tuxdriver.com>,
	"Jiri Pirko" <jpirko@redhat.com>,
	"Jeff Kirsher" <jeffrey.t.kirsher@intel.com>,
	"Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
	"Ben Hutchings" <bhutchings@solarflare.com>,
	"Herbert Xu" <herbert@gondor.hengli.com.au>
Subject: Re: [PATCH] net: orphan queued skbs if device tx can stall
Date: Tue, 10 Apr 2012 14:25:00 +0300	[thread overview]
Message-ID: <20120410112459.GA28825@redhat.com> (raw)
In-Reply-To: <1334052259.3126.68.camel@edumazet-glaptop>

On Tue, Apr 10, 2012 at 12:04:19PM +0200, Eric Dumazet wrote:
> On Tue, 2012-04-10 at 12:31 +0300, Michael S. Tsirkin wrote:
> 
> > True. Still this is the only interface we have for controlling
> > the internal queue length so it seems safe to assume someone
> > is using it for this purpose.
> > 
> 
> So to workaround a problem in tun, you want to hack net/core/dev.c :(

Sorry about being unclear, I'm just saying that your patch assumes
tx_queue_len == 0 since you set it that way at device init but we can't
rely on this as existing users might have changed that value.
One way to fix would be a patch at the bottom: then we
can leave tun to treat tx_queue_len like it always did.

> Packets in qdisc should not be orphaned.
>
> If you think about it, why do we attach skb to socket in the first
> place ?

Good point. The answer is to avoid skb drops for local sockets by
stopping them, right?

> If its not needed for tun, why should it be needed for other devices ?

Maybe needed but it's already broken for tun since the skbs in the
private queue are orphaned by skb_orphan_try?

> If TUN has a problem being stopped forever, maybe it should take
> appropriate action to flush all packets in qdisc queue after a while, as
> this makes no sense to delay packets forever.
> 

Well arbitrary timers aren't a solid protection, right?
We get out of stalling transmitters forever but a bad VM can still
degrade performance significantly for others...


----

We don't want a queue for tun since it can stall forever, but userspace
might tweak it's tx_queue_len as a way to control RX queue depth,
and we don't want to break userspace. Use a private flag to disable queue.

Warning: untested.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 27883d1..644ca53 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -695,7 +692,7 @@ static void attach_one_default_qdisc(struct net_device *dev,
 {
 	struct Qdisc *qdisc = &noqueue_qdisc;
 
-	if (dev->tx_queue_len) {
+	if (dev->tx_queue_len && !(dev->priv_flags & IFF_TX_CAN_STALL)) {
 		qdisc = qdisc_create_dflt(dev_queue,
 					  &pfifo_fast_ops, TC_H_ROOT);
 		if (!qdisc) {
-- 
MST

  reply	other threads:[~2012-04-10 11:25 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-08 17:13 [PATCH] net: orphan queued skbs if device tx can stall Michael S. Tsirkin
2012-04-08 23:49 ` Herbert Xu
2012-04-08 23:49   ` Herbert Xu
2012-04-09  7:28   ` Michael S. Tsirkin
2012-04-09  7:33     ` Herbert Xu
2012-04-09  7:33       ` Herbert Xu
2012-04-09  7:39       ` Michael S. Tsirkin
2012-04-09  8:29         ` Herbert Xu
2012-04-09  8:29           ` Herbert Xu
2012-04-09  8:34           ` Michael S. Tsirkin
2012-04-09  8:39             ` Herbert Xu
2012-04-09  8:39               ` Herbert Xu
2012-04-09  8:42               ` Michael S. Tsirkin
2012-04-09  9:13                 ` Eric Dumazet
2012-04-10  7:55 ` Eric Dumazet
2012-04-10  8:41   ` Michael S. Tsirkin
2012-04-10  8:55     ` Eric Dumazet
2012-04-10  9:31       ` Michael S. Tsirkin
2012-04-10 10:04         ` Eric Dumazet
2012-04-10 11:25           ` Michael S. Tsirkin [this message]
2012-04-10 11:45             ` Eric Dumazet
2012-04-10 12:41               ` Michael S. Tsirkin
2012-04-10 13:52                 ` Eric Dumazet
2012-04-10 14:10                   ` Michael S. Tsirkin
2012-04-11 21:52                   ` Michael S. Tsirkin
2012-05-08 19:35                   ` Michael S. Tsirkin
2012-05-08 19:50                   ` 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=20120410112459.GA28825@redhat.com \
    --to=mst@redhat.com \
    --cc=bhutchings@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=hadi@cyberus.ca \
    --cc=herbert@gondor.hengli.com.au \
    --cc=jasowang@redhat.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jpirko@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mirq-linux@rere.qmqm.pl \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=shemminger@vyatta.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.