All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
To: David Miller <davem@davemloft.net>
Cc: stephen@networkplumber.org, hannes@stressinduktion.org,
	max@rfc2324.org, netdev@vger.kernel.org
Subject: Re: [RFC] Stable interface index option
Date: Tue, 1 Dec 2015 16:06:08 -0500	[thread overview]
Message-ID: <20151201210608.GB23178@oracle.com> (raw)
In-Reply-To: <20151201.155725.733555238839381632.davem@davemloft.net>

On (12/01/15 15:57), David Miller wrote:

> >> > Also current versions of SNMP provide more useful information about
> >> > network interface slot information in ifDescription
> >> 
> >> Well if they do provide strings, then that is probably a better way
> >> forward than messing with the kernel.
> > 
> > It gives strings based on PCI information but nothing useful
> > on tunnels.
> 
> But at least in theory, that could be extended to do so right?

iirc even for the cisco NOS-es, the snmp ifindex for virtual interfaces
(tunnels, vpc, loopback) etc would not have any slot etc info, but
would have other things (specific to the virtual interface type, e.g.,
FEX interface index had something that was pertinent to fex)

But the bigger reason they had a immutable snmp-ifindex was that
the uspace networking applications could build state based on that
immutable index and hang on to that number, regardless of any renumbering
that happened due to HA/failover.

And, since they did not (in general) have to deal with random third
party apps, they did not have to deal with questions like "what should
POSIX/glibc APIs send - the immutable or the mutable index?" so it
was ok for them to have the complexity of two interface indices.

--Sowmini

  reply	other threads:[~2015-12-01 21:06 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-01 12:04 [RFC] Stable interface index option Maximilian Wilhelm
2015-12-01 15:34 ` Sowmini Varadhan
2015-12-01 15:50   ` Maximilian Wilhelm
2015-12-01 16:02     ` Hannes Frederic Sowa
2015-12-01 16:06       ` Stephen Hemminger
2015-12-01 19:28         ` David Miller
2015-12-01 20:20           ` Stephen Hemminger
2015-12-01 20:57             ` David Miller
2015-12-01 21:06               ` Sowmini Varadhan [this message]
2015-12-01 21:14               ` Hannes Frederic Sowa
2015-12-01 21:44                 ` Stephen Hemminger
2015-12-01 21:54                   ` Hannes Frederic Sowa
2015-12-01 22:31                     ` Stephen Hemminger
2015-12-01 19:27       ` David Miller
2015-12-01 20:26         ` Hannes Frederic Sowa
2015-12-01 22:43           ` Maximilian Wilhelm
2015-12-01 23:58             ` Hannes Frederic Sowa
2015-12-02  1:41               ` Andrew Lunn
2015-12-02 11:03               ` Marcelo Ricardo Leitner
2015-12-01 16:11     ` Sowmini Varadhan
2015-12-01 16:10 Maximilian Wilhelm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151201210608.GB23178@oracle.com \
    --to=sowmini.varadhan@oracle.com \
    --cc=davem@davemloft.net \
    --cc=hannes@stressinduktion.org \
    --cc=max@rfc2324.org \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.