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

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

--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Sep 18, 2004 at 01:42:24PM -0400, Robert Watson wrote:
>=20
> On Sat, 18 Sep 2004, Brooks Davis wrote:
>=20
> > > Have you tried seeing just how many addresses you can add before
> > > getifaddrs() fails to return the complete list?  128k seems like a lo=
t,
> > > 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:
> > >=20
> > > ifconf: 16384 space
> >=20
> > 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.=20
> >=20
> > 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.=
=20
>=20
> 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?

After adding the missing sbuf_delete(), I was able to create 2000
aliases on a vlan.  I think the current practical limit is ~4090.
I'm working on a new version that initially caps the allocation at
MAXPHYS and then retries if it doesn't have enough space.

-- Brooks

--=20
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

--ew6BAiZeqk4r7MaW
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFBTKeYXY6L6fI4GtQRAvqbAKCvG89aJbqr4eVviwwt8C6gGHpVTACgzZ0R
iH1SPAj3HMgUUMsyfU3nMT8=
=dJDW
-----END PGP SIGNATURE-----

--ew6BAiZeqk4r7MaW--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040918212441.GA22566>