All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Florian Westphal <fw@strlen.de>,
	David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, mst@redhat.com
Subject: Re: [PATCH -next] tun: stop tx queue when limit is hit
Date: Mon, 21 Jul 2014 11:19:13 +0200	[thread overview]
Message-ID: <20140721091913.GD21375@breakpoint.cc> (raw)
In-Reply-To: <1405932999.10255.114.camel@edumazet-glaptop2.roam.corp.google.com>

Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2014-07-21 at 10:31 +0200, Florian Westphal wrote:
> > Michael, do you think we could restore the 'stop queue' default
> > behaviour?
> > 
> > Looking at your changelog, the only concern seems to be the
> > 'packets never consumed'/'receiver is stuck forever' case.
> > 
> > What about reverting 5d097109257c03a7184, and then adding some
> > type of tun watchdog that will zap the rcv queue + tx queue wakeup?
> > 
> > That should be quite noisy if we combine it with the WARN_ON
> > you usually get when (physical) NIC driver detect stalled tx unit.
> > 
> > What do you think?
> 
> Note that this patch had the ability to choose the behavior (drop or
> back pressure)
> 
>  http://patchwork.ozlabs.org/patch/338951/ ?

Eric, many thanks for this pointer.  In fact, the related discussions
in v2 of the patchset (http://patchwork.ozlabs.org/patch/338803/)
also answers my questions above.

[ the concern is with applications that can get stuck just because
  packet they sent is queued forever ]

I need to think about this some more, but in any case Michael outlined
a possible solution (limit queue delay) in the thread above.

Thanks,
Florian

      reply	other threads:[~2014-07-21  9:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-20 18:51 [PATCH -next] tun: stop tx queue when limit is hit Florian Westphal
2014-07-21  5:33 ` David Miller
2014-07-21  6:54   ` Florian Westphal
2014-07-21  8:31     ` Florian Westphal
2014-07-21  8:56       ` Eric Dumazet
2014-07-21  9:19         ` Florian Westphal [this message]

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=20140721091913.GD21375@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=mst@redhat.com \
    --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 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.