From: David Woodhouse <dwmw2@infradead.org>
To: Benjamin LaHaise <bcrl@kvack.org>
Cc: Nathan Williams <nathan@traverse.com.au>,
Karl Hiramoto <karl@hiramoto.org>,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
John Crispin <blogic@openwrt.org>
Subject: Re: PPPoE performance regression
Date: Wed, 13 Jun 2012 17:11:34 +0100 [thread overview]
Message-ID: <1339603894.14785.5.camel@shinybook.infradead.org> (raw)
In-Reply-To: <20120613155541.GD2361@kvack.org>
[-- Attachment #1: Type: text/plain, Size: 931 bytes --]
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
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
next prev parent reply other threads:[~2012-06-13 16:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1339143949.24571.72.camel@dualcore.traverse>
[not found] ` <1339144110.13998.1.camel@i7.infradead.org>
[not found] ` <1339144954.24571.80.camel@dualcore.traverse>
[not found] ` <1339147045.13998.3.camel@i7.infradead.org>
[not found] ` <1339289425.2661.27.camel@laptop>
2012-06-10 8:32 ` PPPoE performance regression David Woodhouse
2012-06-13 9:57 ` David Woodhouse
2012-06-13 13:50 ` David Woodhouse
2012-06-13 15:55 ` Benjamin LaHaise
2012-06-13 16:11 ` David Woodhouse [this message]
2012-06-13 16:31 ` Benjamin LaHaise
2012-06-13 16:32 ` David Laight
2012-06-13 16:59 ` David Woodhouse
2012-06-13 16:53 ` David Woodhouse
2012-06-13 17:21 ` Benjamin LaHaise
2012-06-13 17:43 ` David Woodhouse
2012-06-14 6:18 ` Paul Mackerras
2012-06-14 6:49 ` David Woodhouse
2012-06-14 10:35 ` David Woodhouse
2012-06-13 20:17 ` Karl Hiramoto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1339603894.14785.5.camel@shinybook.infradead.org \
--to=dwmw2@infradead.org \
--cc=bcrl@kvack.org \
--cc=blogic@openwrt.org \
--cc=davem@davemloft.net \
--cc=karl@hiramoto.org \
--cc=nathan@traverse.com.au \
--cc=netdev@vger.kernel.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).