From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Roopa Prabhu <roopa@cumulusnetworks.com>
Cc: Jiri Pirko <jiri@resnulli.us>, David Ahern <dsahern@gmail.com>,
netdev <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>,
Stephen Hemminger <sthemmin@microsoft.com>,
dcbw@redhat.com, Michal Kubecek <mkubecek@suse.cz>,
Andrew Lunn <andrew@lunn.ch>,
parav@mellanox.com, Saeed Mahameed <saeedm@mellanox.com>,
mlxsw <mlxsw@mellanox.com>
Subject: Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames
Date: Mon, 12 Aug 2019 14:43:10 -0700 [thread overview]
Message-ID: <20190812144310.442869de@cakuba.netronome.com> (raw)
In-Reply-To: <CAJieiUhqAvqvxDZk517hWQP4Tx3Hk2PT7Yjq6NSGk+pB_87q8A@mail.gmail.com>
On Mon, 12 Aug 2019 08:13:39 -0700, Roopa Prabhu wrote:
> On Mon, Aug 12, 2019 at 1:31 AM Jiri Pirko <jiri@resnulli.us> wrote:
> > Mon, Aug 12, 2019 at 03:37:26AM CEST, dsahern@gmail.com wrote:
> > >On 8/11/19 7:34 PM, David Ahern wrote:
> > >> On 8/10/19 12:30 AM, Jiri Pirko wrote:
> > >>> Could you please write me an example message of add/remove?
> > >>
> > >> altnames are for existing netdevs, yes? existing netdevs have an id and
> > >> a name - 2 existing references for identifying the existing netdev for
> > >> which an altname will be added. Even using the altname as the main
> > >> 'handle' for a setlink change, I see no reason why the GETLINK api can
> > >> not take an the IFLA_ALT_IFNAME and return the full details of the
> > >> device if the altname is unique.
> > >>
> > >> So, what do the new RTM commands give you that you can not do with
> > >> RTM_*LINK?
> > >
> > >To put this another way, the ALT_NAME is an attribute of an object - a
> > >LINK. It is *not* a separate object which requires its own set of
> > >commands for manipulating.
> >
> > Okay, again, could you provide example of a message to add/remove
> > altname using existing setlink message? Thanks!
>
> Will the below work ?... just throwing an example for discussion:
>
> make the name list a nested list
> IFLA_ALT_NAMES
> IFLA_ALT_NAME_OP /* ADD or DEL used with setlink */
> IFLA_ALT_NAME
> IFLA_ALT_NAME_LIST
>
> With RTM_NEWLINK you can specify a list to set and unset
> With RTM_SETLINK you can specify an individual name with a add or del op
>
> notifications will always be RTM_NEWLINK with the full list.
>
> The nested attribute can be structured differently.
>
> Only thing is i am worried about increasing the size of link dump and
> notification msgs.
Is not adding commands better because it's easier to deal with the
RTM_NEWLINK notification? I must say it's unclear from the thread why
muxing the op through RTM_SETLINK is preferable. IMHO new op is
cleaner, do we have precedent for such IFLA_.*_OP-style attributes?
next prev parent reply other threads:[~2019-08-12 21:43 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-19 11:00 [patch net-next rfc 0/7] net: introduce alternative names for network interfaces Jiri Pirko
2019-07-19 11:00 ` [patch net-next rfc 1/7] net: procfs: use index hashlist instead of name hashlist Jiri Pirko
2019-07-19 11:00 ` [patch net-next rfc 2/7] net: introduce name_node struct to be used in hashlist Jiri Pirko
2019-07-19 16:29 ` Stephen Hemminger
2019-07-19 19:17 ` Jiri Pirko
2019-07-19 20:26 ` Stephen Hemminger
2019-07-20 7:15 ` Jiri Pirko
2019-09-13 9:52 ` Jiri Pirko
2019-08-08 4:34 ` kbuild test robot
2019-07-19 11:00 ` [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames Jiri Pirko
2019-07-20 3:58 ` Jakub Kicinski
2019-07-20 7:20 ` Jiri Pirko
2019-08-09 4:11 ` Roopa Prabhu
2019-08-09 6:25 ` Jiri Pirko
2019-08-09 15:40 ` Roopa Prabhu
2019-08-09 15:46 ` Michal Kubecek
2019-08-10 13:46 ` Roopa Prabhu
2019-08-10 15:50 ` Michal Kubecek
2019-08-10 19:39 ` Roopa Prabhu
2019-08-11 22:10 ` Michal Kubecek
2019-08-12 15:21 ` Roopa Prabhu
2019-08-12 15:43 ` Michal Kubecek
2019-08-09 16:14 ` David Ahern
2019-08-10 6:30 ` Jiri Pirko
2019-08-12 1:34 ` David Ahern
2019-08-12 1:37 ` David Ahern
2019-08-12 8:31 ` Jiri Pirko
2019-08-12 15:13 ` Roopa Prabhu
2019-08-12 21:43 ` Jakub Kicinski [this message]
2019-08-13 0:29 ` David Ahern
2019-08-13 6:53 ` Jiri Pirko
2019-08-13 6:51 ` Jiri Pirko
2019-08-12 15:40 ` Stephen Hemminger
2019-08-12 16:23 ` Roopa Prabhu
2019-08-13 6:55 ` Jiri Pirko
2019-08-12 16:01 ` David Ahern
2019-08-13 6:56 ` Jiri Pirko
2019-08-26 16:09 ` Jiri Pirko
2019-08-26 16:55 ` Jakub Kicinski
2019-08-26 21:46 ` David Ahern
2019-08-26 22:15 ` Jakub Kicinski
2019-08-26 22:18 ` David Miller
2019-08-26 22:24 ` David Ahern
2019-08-26 22:25 ` David Miller
2019-08-27 0:17 ` David Ahern
2019-08-27 5:09 ` Michal Kubecek
2019-08-27 7:08 ` Jiri Pirko
2019-08-27 8:22 ` David Miller
2019-08-27 9:35 ` Jiri Pirko
2019-08-27 15:14 ` Roopa Prabhu
2019-08-28 7:07 ` Jiri Pirko
2019-08-29 4:36 ` Roopa Prabhu
2019-08-29 5:26 ` Michal Kubecek
2019-08-30 14:35 ` Roopa Prabhu
2019-08-30 14:47 ` David Ahern
2019-08-30 17:04 ` Jiri Pirko
2019-08-30 14:49 ` Michal Kubecek
2019-08-30 17:03 ` Jiri Pirko
2019-09-12 11:59 ` Jiri Pirko
2019-09-13 8:21 ` Jiri Pirko
2019-09-13 14:50 ` Jiri Pirko
2019-08-27 4:55 ` Michal Kubecek
2019-08-27 13:43 ` David Ahern
2019-08-10 6:32 ` Jiri Pirko
2019-07-19 11:00 ` [patch net-next rfc 4/7] net: rtnetlink: put alternative names to getlink message Jiri Pirko
2019-07-20 3:59 ` Jakub Kicinski
2019-07-20 7:17 ` Jiri Pirko
2019-07-19 11:00 ` [patch net-next rfc 5/7] net: rtnetlink: unify the code in __rtnl_newlink get dev with the rest Jiri Pirko
2019-07-19 11:00 ` [patch net-next rfc 6/7] net: rtnetlink: introduce helper to get net_device instance by ifname Jiri Pirko
2019-07-19 11:00 ` [patch net-next rfc 7/7] net: rtnetlink: add possibility to use alternative names as message handle Jiri Pirko
2019-07-20 3:59 ` Jakub Kicinski
2019-07-20 7:22 ` Jiri Pirko
2019-07-19 11:03 ` [patch iproute2 rfc 1/2] ip: add support for alternative name addition/deletion/list Jiri Pirko
2019-07-19 11:03 ` [patch iproute2 rfc 2/2] ip: allow to use alternative names as handle Jiri Pirko
2019-07-19 16:31 ` [patch net-next rfc 0/7] net: introduce alternative names for network interfaces Stephen Hemminger
2019-07-19 19:16 ` Jiri Pirko
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=20190812144310.442869de@cakuba.netronome.com \
--to=jakub.kicinski@netronome.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=dcbw@redhat.com \
--cc=dsahern@gmail.com \
--cc=jiri@resnulli.us \
--cc=mkubecek@suse.cz \
--cc=mlxsw@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=parav@mellanox.com \
--cc=roopa@cumulusnetworks.com \
--cc=saeedm@mellanox.com \
--cc=sthemmin@microsoft.com \
/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.