On 1/19/17 11:10 PM, David Ahern wrote: > This series closes a couple of gaps between IPv4 and IPv6 with respect > to multipath routes: ... > In both cases, the new behavior requires users to opt in by setting a new > flag, RTM_F_ALL_NEXTHOPS, in the rtm_flags of struct rtmsg which is > expected to be the ancillary header in the netlink request received from > the user. A program must opt in to the new behavior so as to not break > any existing applications. > > The opt-in behavior works for both route deletes and dumps (the two > differences noted above), but not for notifications as notifications > do not take user input to specify flags. The only way to have > notifications generate RTA_MULTIPATH encodings is to have a gobal > flag -- e.g., sysctl. I'd prefer not to add a sysctl knob for this > backwards compatibility.
BTW, I am in favor of not requiring a user API for this but just doing it. I can't imagine anyone working with multipath routes not wanting the efficiency of the RTA_MULTIPATH attribute. These patches require an API only because of the rule not to break userspace. If we conclude to just do it without an API, the multipath_add and multipath_del need to be modified to only send a notification once at the end of the actions.
