From: Jiri Pirko <jiri@resnulli.us>
To: Roopa Prabhu <roopa@cumulusnetworks.com>
Cc: David Miller <davem@davemloft.net>,
Jakub Kicinski <jakub.kicinski@netronome.com>,
David Ahern <dsahern@gmail.com>, netdev <netdev@vger.kernel.org>,
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: Wed, 28 Aug 2019 09:07:11 +0200 [thread overview]
Message-ID: <20190828070711.GE2312@nanopsycho> (raw)
In-Reply-To: <CAJieiUjpE+o-=x2hQcsKQJNxB8O7VLHYw2tSnqzTFRuy_vtOxw@mail.gmail.com>
Tue, Aug 27, 2019 at 05:14:49PM CEST, roopa@cumulusnetworks.com wrote:
>On Tue, Aug 27, 2019 at 2:35 AM Jiri Pirko <jiri@resnulli.us> wrote:
>>
>> Tue, Aug 27, 2019 at 10:22:42AM CEST, davem@davemloft.net wrote:
>> >From: Jiri Pirko <jiri@resnulli.us>
>> >Date: Tue, 27 Aug 2019 09:08:08 +0200
>> >
>> >> Okay, so if I understand correctly, on top of separate commands for
>> >> add/del of alternative names, you suggest also get/dump to be separate
>> >> command and don't fill this up in existing newling/getlink command.
>> >
>> >I'm not sure what to do yet.
>> >
>> >David has a point, because the only way these ifnames are useful is
>> >as ways to specify and choose net devices. So based upon that I'm
>> >slightly learning towards not using separate commands.
>>
>> Well yeah, one can use it to handle existing commands instead of
>> IFLA_NAME.
>>
>> But why does it rule out separate commands? I think it is cleaner than
>> to put everything in poor setlink messages :/ The fact that we would
>> need to add "OP" to the setlink message just feels of. Other similar
>> needs may show up in the future and we may endup in ridiculous messages
>> like:
>>
>> SETLINK
>> IFLA_NAME eth0
>> IFLA_ATLNAME_LIST (nest)
>> IFLA_ALTNAME_OP add
>> IFLA_ALTNAME somereallylongname
>> IFLA_ALTNAME_OP del
>> IFLA_ALTNAME somereallyreallylongname
>> IFLA_ALTNAME_OP add
>> IFLA_ALTNAME someotherreallylongname
>> IFLA_SOMETHING_ELSE_LIST (nest)
>> IFLA_SOMETHING_ELSE_OP add
>> ...
>> IFLA_SOMETHING_ELSE_OP del
>> ...
>> IFLA_SOMETHING_ELSE_OP add
>> ...
>>
>> I don't know what to think about it. Rollbacks are going to be pure hell :/
>
>I don't see a huge problem with the above. We need a way to solve this
>anyways for other list types in the future correct ?.
>The approach taken by this series will not scale if we have to add a
>new msg type and header for every such list attribute in the future.
Do you have some other examples in mind? So far, this was not needed.
>
>A good parallel here is bridge vlan which uses RTM_SETLINK and
>RTM_DELLINK for vlan add and deletes. But it does have an advantage of
>a separate
>msg space under AF_BRIDGE which makes it cleaner. Maybe something
>closer to that can be made to work (possibly with a msg flag) ?.
1) Not sure if AF_BRIDGE is the right example how to do things
2) See br_vlan_info(). It is not an OP-PER-VLAN. You either add or
delete all passed info, depending on the cmd (RTM_SETLINK/RTM_DETLINK).
>
>Would be good to have a consistent way to update list attributes for
>future needs too.
Okay. Do you suggest to have new set of commands to handle
adding/deleting lists of items? altNames now, others (other nests) later?
Something like:
CMD SETLISTS
IFLA_NAME eth0
IFLA_ATLNAME_LIST (nest)
IFLA_ALTNAME somereallylongname
IFLA_ALTNAME somereallyreallylongname
IFLA_ALTNAME someotherreallylongname
IFLA_SOMETHING_ELSE_LIST (nest)
IFLA_SOMETHING_ELSE
IFLA_SOMETHING_ELSE
IFLA_SOMETHING_ELSE
CMD DELLISTS
IFLA_NAME eth0
IFLA_ATLNAME_LIST (nest)
IFLA_ALTNAME somereallylongname
IFLA_ALTNAME somereallyreallylongname
IFLA_ALTNAME someotherreallylongname
IFLA_SOMETHING_ELSE_LIST (nest)
IFLA_SOMETHING_ELSE
IFLA_SOMETHING_ELSE
IFLA_SOMETHING_ELSE
How does this sound?
next prev parent reply other threads:[~2019-08-28 7:07 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
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 [this message]
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=20190828070711.GE2312@nanopsycho \
--to=jiri@resnulli.us \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=dcbw@redhat.com \
--cc=dsahern@gmail.com \
--cc=jakub.kicinski@netronome.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).