From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Westphal Subject: Re: [PATCH -next] tun: stop tx queue when limit is hit Date: Mon, 21 Jul 2014 10:31:06 +0200 Message-ID: <20140721083106.GC21375@breakpoint.cc> References: <1405882285-3072-1-git-send-email-fw@strlen.de> <20140720.223313.1589952322700027038.davem@davemloft.net> <20140721065419.GB21375@breakpoint.cc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Miller , netdev@vger.kernel.org, mst@redhat.com To: Florian Westphal Return-path: Received: from Chamillionaire.breakpoint.cc ([80.244.247.6]:52780 "EHLO Chamillionaire.breakpoint.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753753AbaGUIbM (ORCPT ); Mon, 21 Jul 2014 04:31:12 -0400 Content-Disposition: inline In-Reply-To: <20140721065419.GB21375@breakpoint.cc> Sender: netdev-owner@vger.kernel.org List-ID: Florian Westphal wrote: > David Miller wrote: > > From: Florian Westphal > > Date: Sun, 20 Jul 2014 20:51:25 +0200 > > > > > Currently tun just frees the skb and returns NETDEV_TX_OK > > > when queue length exceeds txqlen. > > > > > > This causes severe packetloss and unneeded resource > > > consumption on host when sending to vm connected via tun. > > > > > > Instead, lets stop the transmit queue and start it once > > > packets are consumed from the queue. This allows the network > > > stack to control applications that send data via tun device. > > > > I strongly suspect the current behavior is intentional, see > > commit: > > > > commit 5d097109257c03a71845729f8db6b5770c4bbedc > > Author: Michael S. Tsirkin > > Date: Mon Dec 3 10:07:14 2012 +0000 > > > > tun: only queue packets on device > > Looks like you're right :-/ > > Alright, please ignore my patch. > > That being said, the current behaviour isn't ideal either. > > It took me quite some time to realize that packetloss > was on the sender side inside tun driver and not on the receiver > vm. Not stopping the queue was a bit ... unexpected. 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?