[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1449001579.3817695.455078657.261B9C10@webmail.messagingengine.com>
Date: Tue, 01 Dec 2015 21:26:19 +0100
From: Hannes Frederic Sowa <hannes@...essinduktion.org>
To: David Miller <davem@...emloft.net>
Cc: max@...2324.org, netdev@...r.kernel.org
Subject: Re: [RFC] Stable interface index option
On Tue, Dec 1, 2015, at 20:27, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@...essinduktion.org>
> Date: Tue, 01 Dec 2015 17:02:23 +0100
>
> > On Tue, Dec 1, 2015, at 16:50, Maximilian Wilhelm wrote:
> >> > I'm not sure I understand how this would work- are we going to
> >> > pin down the ifindex for some subset of interfaces?
> >>
> >> I'm not sure what your idea is, but I guess we might mean the same
> >> thing:
> >>
> >> What I have in mind is that the user can supply a list of (ifname ->
> >> ifindex) entries via a sysfs/procfs interface and if such a list is
> >> present, the kernel will search the list for every ifname which is
> >> registered and check if there is an entry. If there is, the ifindex
> >> for this entry is used. If there is no entry found for the given
> >> ifname, the usual algorithm is used (therefore inherently providing
> >> backward compatibility).
> >
> > Sorry to ask because I don't like this feature at all. There was a lot
> > of work on stable interface names. Why do you need stable ifindexes,
> > which were never meant to be stable for a longer amount of time?
>
> Because all the remote SNMP tools work with interface indexes, not names.
I know, but it should be terribly simply to patch SNMP tools to even
store the table of ifindex <-> name mappings persistently on the disk
and thus completely avoid this issue. Even though they can check on
interfaces if they have the same characteristics, e.g. tunnel to the
same destinations etc. Those are all policies which user space should
handle.
I agree it would make life much easier for user space if the kernel
would keep the ifindex stable over reboots etc. but for a much higher
costs at kernel maintenance.
Bye,
Hannes
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists