Andi Kleen wrote:
> On Fri, Oct 13, 2000 at 06:00:15AM +0200, Ben Greear wrote:
> > Andi Kleen wrote:
> > >
> > > On Wed, Oct 11, 2000 at 08:54:21AM +0200, Ben Greear wrote:
> > > > I'm trying to write a hash structure that will hold the devices,
> > > > hashed by both name and index.
> > > >
> > > > It seems that the devices are first named generically: eth%d,
> > > > and at some later date, are initialized correctly. This, of course,
> > > > completely screws up any name-based hashing I might have had...
> > > >
> > > > If names can change at any time, then I'll just quit trying to
> > > > hash on them. However, if they only change up to some certain
> > > > step, then I'll be able to just initialize the hash list after that.
> > > >
> > > > Are the device names (for the devices in dev_base) un-changable after
> > > > some point? What is this point? (Would 'at-the-first-dev-add' be ok?)
> > >
> > > Root can change them anytime using SIOCSIFNAME. I wrote a small program
> > > to rename net devices based on the MAC address, which used it successfully
> > > (so eth0 was always the same adapter, no matter how the modules were
> > > loaded)
> > What if I remove the device from the hash before the name change, and
> > add it back again after? That should preserve the hash, and I assume that
> > the devices will not be renamed regularly, so the slight performance hit
> > should not be a problem. I'll probably have to lock the structures
> > (read/write dev_base), just as the register_netdevice() does...
> I am not sure I understand your problem. You probably want two hash
> tables, one for the ifindex and one for the ifname. These are separated.
> When ifindex or name change you update the appropiate hash table chains under
> their lock.
I have two tables, but was told that ifindex cannot change, so don't have to
worry about that one...
I didn't want to add an extra lock because I don't expect ppl to be re-naming
devices too often, and right now, the code that needs locking is already
protected by the already-existing dev_base locks. I figure that having one
slightly coarser lock around rarely used code (change_name(..)) was preferable
to adding another
lock around more often-run code (the dev_get_**). I'll separate out the patch
from my VLAN code and post it for examinations this weekend..when it's written
> > I mean, doesn't everyone need 4k VLAN interfaces?? :)
> Apparently people do, I recently had to fix a O(n^2) algorithm in ifconfig
> which made printout of thousands of interfaces very slow ...
I noticed that my hack brought an ifconfig -a of 1000 devices from about 7
to about 1 second on my Celeron 500. However, I think I might still be using
algorithm ifconfig, because it became about 20 seconds on 4k devices (with my
Ben Greear (greearb@xxxxxxxxxxxxxxx) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com 4444 (Released under GPL)