Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Sep 2004 13:42:24 -0400 (EDT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Brooks Davis <brooks@one-eyed-alien.net>
Cc:        current@FreeBSD.org
Subject:   Re: 5.3-RELEASE TODO
Message-ID:  <Pine.NEB.3.96L.1040918134100.91851A-100000@fledge.watson.org>
In-Reply-To: <20040918171216.GA27533@odin.ac.hmc.edu>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sat, 18 Sep 2004, Brooks Davis wrote:

> > Have you tried seeing just how many addresses you can add before
> > getifaddrs() fails to return the complete list?  128k seems like a lot,
> > but I instrumente ifconf() locally a couple of weeks ago when I first
> > became aware of this problem, and discovered that even on my notebook
> > (which has a wireless card with one IP, and an unused ethernet card) that
> > I see moderately large buffers being read from user space:
> > 
> > ifconf: 16384 space
> 
> Those allocations don't seem to make any sense.  The actual space
> required is quite small.  All you do is copy one struct ifreq out for
> each address, plus one for each interface with no addresses.  The base
> size of a struct ifreq is 32 bytes and it extends to 34 for IPv6
> addresses.  The maximum size allowed by the data types is 273 (for a 255
> byte address).  Since I think IPv6 are the largest addresses used in
> practice, MAXPHYS is probably not too bad, though it does put a new cap
> on the number of interfaces at ~4k. 
> 
> If we want to keep kernel allocations small and allow all the itnerfaces
> to be reliably reported, we probably need to go back to my origional
> plan where we loop repeatidly.  I might do it differently by allocating
> up to MAXPHYS and only reallocating if we overflow.  That would avoid
> doing it twice (or more) on normal machines while still being correct. 

I'm not too worried about theory, mostly about practice.  I.e., if you add
a few thousand IP addresses to a tap device, does all go happily?

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org      Principal Research Scientist, McAfee Research




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040918134100.91851A-100000>