100 network limit

100 network limit

[Anton Blanchard]

Hi,

We hit the 100 network naming limit :) Yes the comment is correct, we
need to fix the algorithm. dev_base_lock really starts to show up
(eg in dev_get_by_index), especially when doing IO to raw sockets
(does every packet to a raw socket result in a dev_get_by_index? Couldnt
we embed a pointer to the device in the socket?)

Anyway as a short term fix Jamal suggested making a sysctl for this
maximum. If fixing this all properly is out of the question for 2.6,
would the sysctl approach be satisfactory? The other option is to just
bump the limit and recognise that the user is on his own if performance
sucks.

Anton

diff -ru gr14/net/core/dev.c gr14_work/net/core/dev.c
--- gr14/net/core/dev.c	2003-08-18 13:40:43.000000000 -0500
+++ gr14_work/net/core/dev.c	2003-08-28 12:56:45.000000000 -0500
@@ -630,9 +630,9 @@
 		return -EINVAL;
 
 	/*
-	 * If you need over 100 please also fix the algorithm...
+	 * If you need over 200 please also fix the algorithm...
 	 */
-	for (i = 0; i < 100; i++) {
+	for (i = 0; i < 200; i++) {
 		snprintf(buf, sizeof(buf), name, i);
 		if (!__dev_get_by_name(buf)) {
 			strcpy(dev->name, buf);

Re: 100 network limit

[Andi Kleen]

On Fri, 29 Aug 2003 04:00:19 +1000
Anton Blanchard <anton@samba.org> wrote:


> Anyway as a short term fix Jamal suggested making a sysctl for this
> maximum. If fixing this all properly is out of the question for 2.6,
> would the sysctl approach be satisfactory? The other option is to just
> bump the limit and recognise that the user is on his own if performance
> sucks.

You could just add a bitmap with a reasonable upper limit (1024?) and use 
find_first_zero_bit()  I doubt doing that would be very intrusive.

-Andi

Re: 100 network limit

[Ben Greear]

Andi Kleen wrote:
> On Fri, 29 Aug 2003 04:00:19 +1000
> Anton Blanchard <anton@samba.org> wrote:
> 
> 
> 
>>Anyway as a short term fix Jamal suggested making a sysctl for this
>>maximum. If fixing this all properly is out of the question for 2.6,
>>would the sysctl approach be satisfactory? The other option is to just
>>bump the limit and recognise that the user is on his own if performance
>>sucks.
> 
> 
> You could just add a bitmap with a reasonable upper limit (1024?) and use 
> find_first_zero_bit()  I doubt doing that would be very intrusive.
> 
> -Andi

Since you can rename devices, that might not work.  A long time ago I
hashed the devices, both by name and by index...that gives good lookup performance, at least.  As for
create-time issues, that is definately slow path, and even searching linearly
4 or 8k devices is not a big deal (in my opinion).  So, why not make the hard-coded
100 limit be more like 8196 or something really large?  (It could still be adjustable
if needed.)

Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: 100 network limit

[David S. Miller]

On Thu, 28 Aug 2003 14:46:39 -0700
Ben Greear <greearb@candelatech.com> wrote:

> Since you can rename devices, that might not work.  A long time ago
> I hashed the devices, both by name and by index...that gives good
> lookup performance, at least.  As for create-time issues, that is
> definately slow path, and even searching linearly 4 or 8k devices is
> not a big deal (in my opinion).  So, why not make the hard-coded 100
> limit be more like 8196 or something really large?  (It could still
> be adjustable if needed.)

Right, it's also not going to fix the locking problems.

I would suggest two things:

1) Ben's hashing patch for lookups.

2) RCU'ing read access to the device list.

Re: 100 network limit

[Ben Greear]

David S. Miller wrote:
> On Thu, 28 Aug 2003 14:46:39 -0700
> Ben Greear <greearb@candelatech.com> wrote:
> 
> 
>>Since you can rename devices, that might not work.  A long time ago
>>I hashed the devices, both by name and by index...that gives good
>>lookup performance, at least.  As for create-time issues, that is
>>definately slow path, and even searching linearly 4 or 8k devices is
>>not a big deal (in my opinion).  So, why not make the hard-coded 100
>>limit be more like 8196 or something really large?  (It could still
>>be adjustable if needed.)
> 
> 
> Right, it's also not going to fix the locking problems.
> 
> I would suggest two things:
> 
> 1) Ben's hashing patch for lookups.
> 
> 2) RCU'ing read access to the device list.
> 

I'm at least mostly on vacation for a week or so...  Here is a pointer
to the old patch I did..but it's ~2.5 years old.  If anyone wants
to get it working with recent code, please be my guest.

Otherwise, I'll try to get something together in a few weeks.

http://www.cs.helsinki.fi/linux/linux-kernel/2001-00/1227.html

Take it easy,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: 100 network limit

[Andi Kleen]

On Thu, 28 Aug 2003 14:46:39 -0700
Ben Greear <greearb@candelatech.com> wrote:

> 
> Since you can rename devices, that might not work. 

When someone renames eth1 to eth2 and the bitmap  doesn't have eth2 set and selects it 
then you can just retry, searching for further free bits.

When someone renames eth2 to eth1 the rename code should just clear the bit
of eth2 before the rename.

-Andi