From: Benjamin LaHaise <bcrl@lhnet.ca>
To: Denys Fedoryschenko <denys@visp.net.lb>
Cc: Mark Smith <lk-netdev@lk-netdev.nosense.org>,
David Miller <davem@davemloft.net>,
shemminger@vyatta.com, opurdila@ixiacom.com,
eric.dumazet@gmail.com, netdev@vger.kernel.org
Subject: Re: [net-next-2.6 PATCH] net: fast consecutive name allocation
Date: Sun, 15 Nov 2009 11:50:15 -0500 [thread overview]
Message-ID: <20091115165015.GU19478@kvack.org> (raw)
In-Reply-To: <200911150355.15204.denys@visp.net.lb>
Hi Denys,
On Sun, Nov 15, 2009 at 03:55:14AM +0200, Denys Fedoryschenko wrote:
> And interface creation speed is important for me, when electricity goes down
> here, many customers disconnects (up to 500 on single NAS), and then join
> again to NAS. Load average was jumping to sky on such situations, just option
> to not create sysfs entries helped me a lot (was posted recently).
> Electricity outage is usual here, happens 2-3 times daily.
This is exactly the type of scenario I'm looking at. The design of the
Babylon PPP stack is meant to scale somewhat better that pppd. It uses a
single process (although I'm starting to add threads to improve scaling on
SMP systems) for all PPP/L2TP sessions, and has rather lower connection
setup overhead (no fork()/exec() being the biggest one). With udev tuned,
irqbalance disabled and a few other tweaks, it gets >500 connections per
second in startup on a modern 2.6GHz processor for L2TP traffic. There
is PPPoE support, but it needs a bit more work done to scale automatically
(there are a few hardcoded limits in the PPPoE implementation).
-ben
next prev parent reply other threads:[~2009-11-15 16:50 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-13 5:01 [net-next-2.6 PATCH] net: fast consecutive name allocation Octavian Purdila
2009-11-13 5:20 ` Octavian Purdila
2009-11-13 6:12 ` Eric Dumazet
2009-11-13 6:26 ` Stephen Hemminger
2009-11-13 7:09 ` Eric Dumazet
2009-11-13 9:51 ` Octavian Purdila
2009-11-13 22:29 ` Stephen Hemminger
2009-11-13 22:40 ` Benjamin LaHaise
2009-11-13 22:49 ` Stephen Hemminger
2009-11-13 23:35 ` Benjamin LaHaise
2009-11-13 23:39 ` Stephen Hemminger
2009-11-13 23:52 ` Benjamin LaHaise
2009-11-14 2:59 ` David Miller
2009-11-14 6:24 ` Benjamin LaHaise
2009-11-14 22:36 ` Mark Smith
2009-11-15 1:22 ` Stephen Hemminger
2009-11-15 1:49 ` Mark Smith
2009-11-15 1:55 ` Denys Fedoryschenko
2009-11-15 7:48 ` Eric Dumazet
2009-11-15 16:50 ` Benjamin LaHaise [this message]
2009-11-14 7:08 ` Benny Amorsen
2009-11-14 7:21 ` Eric Dumazet
2009-11-14 16:16 ` Ben Greear
2009-11-13 9:55 ` Octavian Purdila
2009-11-13 16:40 ` Ben Greear
2009-11-14 0:04 ` Stephen Hemminger
2009-11-14 0:14 ` Octavian Purdila
2009-11-14 0:20 ` Stephen Hemminger
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=20091115165015.GU19478@kvack.org \
--to=bcrl@lhnet.ca \
--cc=davem@davemloft.net \
--cc=denys@visp.net.lb \
--cc=eric.dumazet@gmail.com \
--cc=lk-netdev@lk-netdev.nosense.org \
--cc=netdev@vger.kernel.org \
--cc=opurdila@ixiacom.com \
--cc=shemminger@vyatta.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.