netdev - Re: tuntap: Overload handling

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]

Date:	Sun, 17 Feb 2013 17:08:13 +0100
From:	Sebastian Pöhn <sebastian.poehn@...glemail.com>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Subject: Re: tuntap: Overload handling

On Sun, 2013-02-17 at 15:24 +0200, Michael S. Tsirkin wrote:
> On Thu, Feb 14, 2013 at 09:01:30AM -0800, Eric Dumazet wrote:
> > On Thu, 2013-02-14 at 18:42 +0200, Michael S. Tsirkin wrote:
> > 
> > > Hmm so ~1000 packets in the tun queue is not enough?
> > > You always have the option to increase it some more ...
> > > 
> > > > You should ask Michael S. Tsirkin, as he removed the flow control
> > > > in commit 5d097109257c03a71845729f8db6b5770c4bbedc
> > > > (tun: only queue packets on device)
> > > > 
> > > 
> > > Eric in the past you said the following things
> > > (http://lkml.indiana.edu/hypermail/linux/kernel/1204.1/00784.html)
> > > > > In your case I would just not use qdisc at all, like other virtual
> > > > > devices.
> > > ...
> > > > > Anyway, with a 500 packet limit in TUN queue itself, qdisc layer should
> > > > > be always empty. Whats the point storing more than 500 packets for a
> > > > > device ? Thats a latency killer.
> > > you don't think this applies, anymore?
> > > 
> > 
> > Users have the choice to setup a qdisc or not.
> > 
> > Having no qdisc can help raw performance, at the expense of bufferbloat.
> > Thats all I was saying.
> > 
> > It seems tun.c has no longer the possibility to effectively use a qdisc,
> > (allowing the queue to buildup at qdisc layer)
> > 
> 
> But, userspace is in no position to decide whether using
> the qdisc is a good or a bad thing.
> The issue I tried to solve is that with tun, it's trivially easy for
> userspace to lock up resources forever.
> Simply not stopping the qdisc is probably the simplest solution.
> 
> An alternative is to orphan the skbs before we queue them.
> At some point I posted a proposal doing exactly this
> subj of "net: orphan queued skbs if device tx can stall".
> Do you think it's worth revisiting this?
> 
> Also - does anyone know of a testcase showing there's a problem
> with the simplest solution we now have in place?
> 

I think the solution is good as it is. Of course if you want to do odd
things with it like me - it's not, but that's not its usual use-case.


--
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