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]

Message-ID: <1360861290.6884.55.camel@edumazet-glaptop>
Date:	Thu, 14 Feb 2013 09:01:30 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	Sebastian Pöhn 
	<sebastian.poehn@...glemail.com>, netdev@...r.kernel.org
Subject: Re: tuntap: Overload handling

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)



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