what is the story on if_index allocation ?

[Brooks Davis]

On Mon, Apr 19, 2004 at 11:09:12AM -0700, Luigi Rizzo wrote:
> 
> 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.
> 
> 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

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20040419/9220fd56/attachment.bin