netdev - Re: PPPoE performance regression

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: <1339603894.14785.5.camel@shinybook.infradead.org>
Date:	Wed, 13 Jun 2012 17:11:34 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Benjamin LaHaise <bcrl@...ck.org>
Cc:	Nathan Williams <nathan@...verse.com.au>,
	Karl Hiramoto <karl@...amoto.org>,
	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	Paul Mackerras <paulus@...ba.org>,
	John Crispin <blogic@...nwrt.org>
Subject: Re: PPPoE performance regression

On Wed, 2012-06-13 at 11:55 -0400, Benjamin LaHaise wrote:
> Does this actually work?  Could the skb not end up sitting on the
> receive  queue of a user socket indefinitely, deferring all further
> transmits?  From an ISP point of view, 

I haven't tried it; only compiled it. Certainly, the similar approach in
PPPoATM in commit 9d02daf7 *does* work for limiting the bufferbloat and
keeping the queues under control. And it'll let me do BQL for PPPoA.

I'm looking at this from the client side, not the ISP side. And in that
case the local interface *is* the bottleneck. When it's a PPPoE over
br2684 interface and it's full, we should stop the PPP netdev from
spewing packets at it, rather than just dropping them.

On the ISP side if the skb ends up sitting on a receive queue of a user
socket, and nothing is servicing that socket, surely the transmits on
this channel weren't happening anyway?

-- 
dwmw2

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (6171 bytes)