On 1/30/17 4:13 AM, Nicolas Dichtel wrote: > Le 30/01/2017 à 03:57, David Ahern a écrit : >> On 1/29/17 7:20 PM, Roopa Prabhu wrote: >>>> 2. Delete - 1 notification for each hop for all combinations of delete >>>> commands >>> >>> here I was trying to say, for people deleting the full multipath route, you >>> should send a RTA_MULTIPATH. >> >> The only way to do that is to call inet6_rt_notify() *before* the route >> delete work has been done in fib6_del_route. Right now it is called at the >> end - after all sibling associations have been dropped, a time in which it >> can no longer fill in RTA_MULTIPATH. >> >> fib6_del_route function does not have any failure paths and is called with >> the write lock held, so moving the notification might be ok. But it also >> means ignoring all subsequent failures from fib6_del, again which might be >> ok since the only failure is ENOENT which can not happen if we are walking >> the sibling list. > Is it not possible to prepare the RTA_MULTIPATH attribute during the deletion > (when needed information are still available) and to use/copy it later when > the > notification is done?
What I outlined above has the least complexity and does not require copies. And it is only proper for the 1 case where a multipath route is deleted by prefix and length -- the ability enabled by Patch 2. > > Or at least, having RTA_MUTLTIPATH with one nexthop only, so that the user > knows > that this route was part of an ECMP routes? > For the ip6_route_multipath_del path, sure the nexthops deleted can be wrapped in RTA_MULTIPATH if the nexthop indeed has siblings, but does it help userspace? If all attributes outside of the nexthops are identical, then userspace would match the route without it.
