All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
To: netdev@vger.kernel.org
Subject: Re: [RFC] Stable interface index option
Date: Tue, 1 Dec 2015 11:11:14 -0500	[thread overview]
Message-ID: <20151201161114.GB17843@oracle.com> (raw)
In-Reply-To: <20151201155052.GA14984@principal.rfc2324.org>

On (12/01/15 16:50), Maximilian Wilhelm wrote:
> 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

Having the user supply such a list is hazardous for the reason below,
esp if you consider that you can have virtual interfaces that 
take up that number.  It also allows for a sparse ifindex number
space, which can be inefficient (thus the cisco choice)

> What I'm not sure about is what to do if there is any entry in the
> list but the ifindex is already in use. One option would be to fail
> the register call because the user wanted this particular ifindex ..

If you want to do this, it's simpler to have the kernel
track 2 separate indices (the packed index and the sparse snmp-index)
per net_device. Changes to achieve it are non-trivial, of course,
and that's why I'd question how badly this is needed.

the other issue to confront is- what do you want ioctls like SIOCGIFINDEX
to return- the packed one or the sparse one? What about if_nametoindex etc?
If they return the sparse index, can they use it back with existing
ifioctl and other calls?  i.e., API compat will have some rough edges.

--Sowmini

  parent reply	other threads:[~2015-12-01 16:11 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
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 [this message]
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=20151201161114.GB17843@oracle.com \
    --to=sowmini.varadhan@oracle.com \
    --cc=netdev@vger.kernel.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.