netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Denys Fedoryschenko <denys@visp.net.lb>
Cc: Mark Smith <lk-netdev@lk-netdev.nosense.org>,
	David Miller <davem@davemloft.net>,
	bcrl@lhnet.ca, shemminger@vyatta.com, opurdila@ixiacom.com,
	netdev@vger.kernel.org
Subject: Re: [net-next-2.6 PATCH] net: fast consecutive name allocation
Date: Sun, 15 Nov 2009 08:48:27 +0100	[thread overview]
Message-ID: <4AFFB24B.7050508@gmail.com> (raw)
In-Reply-To: <200911150355.15204.denys@visp.net.lb>

Denys Fedoryschenko a écrit :
> On Sunday 15 November 2009 00:36:04 Mark Smith wrote:
>> On the occasions I've looked at whether a Linux box would be an
>> alternative to the Cisco BRAS platform we use, the last time I looked
>> the number of sessions people were saying they were running was
>> 500. I don't consider Linux to be feasible in that role until you're
>> able to run at least 5000 sessions on a single box. I'm a bit unusual
> I am running up to 3500 on single NAS, but there is only 3 biggest one like 
> this, and i am limited only by subscribers on this location (network is 
> distributed over the country, and i have around 200 NAS servers running in 
> summary). And it is just PC bought from nearest supermarket with cheap PCI 
> RTL8169, and similar quality LOM adapter e1000e. Everything running on 
> cheapest USB flash from same supermarket.
> 
> For my case running Linux NAS on cheap PC's is only choice. It is 3rd world 
> country, and many reasons (i can explain each, but it is not technical 
> subject) doesn't let me to think, that "professional" equipment is feasible 
> for me.
> 
> Here people build networks on cheapest unmanageable switches, same 
> cost/quality 802.11b/g wireless networks, and only a way to terminate them 
> reliably is PPPoE. I know, it is also weak and easy to break, but it is 
> single choice i have.
> I know also ISP's in Russia, who have somehow partially "managed" networks, 
> but PPPoE letting them to drop running costs.
> 
> 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.

I found in my cases (not pppoe) that load was very high because of udev,
doing crazy loops of :

if (!rtnl_trylock())
     return restart_syscall();

About pppoe, we have a 16 slots hash table, protected by a single rwlock.

This wont scale to 50000 sessions, unless we use larger hashtable and
maybe RCU as well.

About the dismantling phase, it is currently a synchronous thing
(as the resquester process has to wait for many rcu grace periods
for each netdevice to dismantle). Thats typically ~20 ms per device !

For 'anonymous' netdevices, we probably could queue them and use a
 worker thread to handle this queue using the new batch mode,
added in net-next-2.6.



  reply	other threads:[~2009-11-15  7:48 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 [this message]
2009-11-15 16:50                           ` Benjamin LaHaise
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=4AFFB24B.7050508@gmail.com \
    --to=eric.dumazet@gmail.com \
    --cc=bcrl@lhnet.ca \
    --cc=davem@davemloft.net \
    --cc=denys@visp.net.lb \
    --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 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).