Date: Mon, 19 Apr 2004 11:33:17 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: Luigi Rizzo <rizzo@icir.org> Cc: net@freebsd.org Subject: Re: what is the story on if_index allocation ? Message-ID: <20040419183316.GE8967@Odin.AC.HMC.Edu> In-Reply-To: <20040419110912.A71274@xorpc.icir.org> References: <20040419110912.A71274@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--pQhZXvAqiZgbeUkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 19, 2004 at 11:09:12AM -0700, Luigi Rizzo wrote: >=20 > I am a bit unclear -- how do we allocate if_index values for > network interfaces ? > I thought the strategy was allocate them sequentially, and > only reuse numbers at the top of the allocated range. > But then i see if_findindex() is quite complicated, and > seems to look for hints using resource_string_value() and > resource_find_dev() to possibly recycle old indexes below > if_index. >=20 > Can someone explain what is the goal ? Reuse a number if an > interface has the same name of a previously existing one and > the index is free ? And does it make sense, anyways, or > we could just simplify that code and just reuse the first > available entry in ifindex_table[] ? > Even the current allocation strategy does not guarantee that > indexes reflect the order of creation of interfaces, if that > is what we care about. harti recently mentioned that the SNMP RFC requires that interfaces keep the same index across various events including loading and unloading the driver. I suspect this code is an attempt to handle that case. Keying off of lladdrs is probably as close as you're going to get to obeying that requirement in the kernel. I'm not convinced we should worry about it in the kernel. The whole concept of the "same interface" is rather dependent on the particular application context. For instance, when dealing with virtual interfaces on a tunnel server, interfaces could be created and destroyed on demand and if you wanted to do accounting via SNMP indexs should be consistant for each account. I'm tempted to push the whole problem off to userland where appropriate application dependent policies can be implemented. -- 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 --pQhZXvAqiZgbeUkD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAhBtsXY6L6fI4GtQRArXyAJ9fbT/XEK+6ygu4A2E4yyx0XE0w1ACeNzIX 0gTVURU9MZuC8iAy0jA/PI4= =JMWr -----END PGP SIGNATURE----- --pQhZXvAqiZgbeUkD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040419183316.GE8967>