From: Benjamin LaHaise <bcrl@kvack.org>
To: David Woodhouse <dwmw2@infradead.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 11:55:41 -0400 [thread overview]
Message-ID: <20120613155541.GD2361@kvack.org> (raw)
In-Reply-To: <1339595401.11011.48.camel@shinybook.infradead.org>
On Wed, Jun 13, 2012 at 02:50:01PM +0100, David Woodhouse wrote:
> On Wed, 2012-06-13 at 10:57 +0100, David Woodhouse wrote:
> > This doesn't look *so* evil... if the basic concept of using
> > skb_orphan() and then setting our own destructor is OK, then I'll work
> > out the rest of the details and do it for l2tp too.
>
> Stupid dwmw2. With patch this time...
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, PPPoE and L2TP are most typically used on links where
the congestion point is not the local interface the packets are being pumped
into (think of the vast majority of ethernet based DSL modems), and this
kind of transmit overhead is a pure waste of CPU cycles. The only solution
that generically works in most PPPoE/L2TP situations is to shape outgoing
traffic to the speed of limiting link.
Maybe there's a PPP extension that does flow control...
-ben
next prev parent reply other threads:[~2012-06-13 15:55 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 [this message]
2012-06-13 16:11 ` David Woodhouse
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=20120613155541.GD2361@kvack.org \
--to=bcrl@kvack.org \
--cc=blogic@openwrt.org \
--cc=davem@davemloft.net \
--cc=dwmw2@infradead.org \
--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).