netdev - Re: [PATCH -next] tun: stop tx queue when limit is hit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140721065419.GB21375@breakpoint.cc>
Date:	Mon, 21 Jul 2014 08:54:20 +0200
From:	Florian Westphal <fw@...len.de>
To:	David Miller <davem@...emloft.net>
Cc:	fw@...len.de, netdev@...r.kernel.org
Subject: Re: [PATCH -next] tun: stop tx queue when limit is hit

David Miller <davem@...emloft.net> wrote:
> From: Florian Westphal <fw@...len.de>
> 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 <mst@...hat.com>
> 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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html