Message-ID: <20190826151552.4f1a2ad9@cakuba.netronome.com>
Date:   Mon, 26 Aug 2019 15:15:52 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     David Ahern <dsahern@...il.com>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        netdev <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Stephen Hemminger <sthemmin@...rosoft.com>, dcbw@...hat.com,
        Michal Kubecek <mkubecek@...e.cz>,
        Andrew Lunn <andrew@...n.ch>, parav@...lanox.com,
        Saeed Mahameed <saeedm@...lanox.com>,
        mlxsw <mlxsw@...lanox.com>
Subject: Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add
 and delete alternative ifnames

On Mon, 26 Aug 2019 15:46:43 -0600, David Ahern wrote:
> On 8/26/19 10:55 AM, Jakub Kicinski wrote:
> > On Mon, 26 Aug 2019 18:09:16 +0200, Jiri Pirko wrote:  
> >> DaveA, Roopa. Do you insist on doing add/remove of altnames in the
> >> existing setlist command using embedded message op attrs? I'm asking
> >> because after some time thinking about it, it still feels wrong to me :/
> >>
> >> If this would be a generic netlink api, we would just add another couple
> >> of commands. What is so different we can't add commands here?
> >> It is also much simpler code. Easy error handling, no need for
> >> rollback, no possibly inconsistent state, etc.  
> > 
> > +1 the separate op feels like a better uapi to me as well.
> > 
> > Perhaps we could redo the iproute2 command line interface to make the
> > name the primary object? Would that address your concern Dave and Roopa?
> 
> No, my point is exactly that a name is not a primary object. A name is
> an attribute of a link - something that exists for the convenience of
> userspace only. (Like the 'protocol' for routes, rules and neighbors.)
> 
> Currently, names are changed by RTM_NEWLINK/RTM_SETLINK. Aliases are
> added and deleted by RTM_NEWLINK/RTM_SETLINK. Why is an alternative name
> so special that it should have its own API?

My feeling is that it's better to introduce operations for this
sub-object than mux everything via setlink :( The use of netlink 
in more recent APIs like devlink is much more liberal when it comes 
to ops and the result is much more convenient and clean IMHO.

Weren't there multiple problems with the size of the RTM_NEWLINK
notification already? Adding multiple sizeable strings to it won't
help there either :S

Do you foresee a need for the alias to be updated atomically with other
RTM_SETLINK changes?

> If only 1 alt name was allowed, then RTM_NEWLINK/RTM_SETLINK would
> suffice. Management of it would have the same semantics as an alias -
> empty string means delete, non-empty string sets the value.
> 
> So really the push for new RTM commands is to handle an unlimited number
> of alt names with the ability to change / delete any one of them. Has
> the need for multiple alternate ifnames been fully established? (I don't
> recall other than a discussion about parallels to block devices.)

I feel like I already posted this link, but here it is again:

https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

IMHO the fact that there are multiple naming schemes in systemd today
is proof enough.


To be clear my (probably over-engineered) position is that "user-
-understandable" interface names had became a dead end already long
time ago. We should move away from strings and try to build APIs or at
least user space where device can be selected based on attributes
directly. The names are nothing else than a random grab bag of
attributes sprintf()-ed together, anyway. 

The naming done by udev is inherently racy and over and over again we
run into races and issues because OvS or some other piece of userspace
gets confused and e.g. enslaves ports to wrong bridges.

Longer names I just a band aid. But I'm under no illusion I can convince
people to spend time working on an attribute-based scheme.. ;)

Powered by blists - more mailing lists