Subject: Re: [net-next-2.6 PATCH] net: fast consecutive name allocation

From: Eric Dumazet <[email-masked]>
Date: Sun, 15 Nov 2009 08:48:27 +0100

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.