Re: [PATCH net-next] ipv6: Move ipv6 stubs to a separate header file

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Sat, Mar 23, 2019 at 09:40:23PM -0400, David Miller wrote:
> From: David Ahern <dsahern@kernel.org>
> Date: Fri, 22 Mar 2019 06:06:09 -0700
> 
> > From: David Ahern <dsahern@gmail.com>
> > 
> > The number of stubs is growing and has nothing to do with addrconf.
> > Move the definition of the stubs to a separate header file and update
> > users. In the move, drop the vxlan specific comment before ipv6_stub.
> > 
> > Code move only; no functional change intended.
> > 
> > Signed-off-by: David Ahern <dsahern@gmail.com>
> 
> Eric, I fully support David's overall plan to make separate nexthop
> objects as it will significantly empower the stack to do more sensible
> things when links flap etc.

let's agree to disagree.
'link flaps' were not mentioned in the cover letter for:
"net: Improve route scalability via support for nexthop objects"

The _only_ value of 86 patches is to align linux kernel routing
with switch ASICs, because cumulus is trying to reuse iproute2
to manage them.
It was broken model to begin with and it keeps complicating routing
when linux is used as a host while not achieving the goal of iproute2
for switches.
Can anyone use off the shelf linux to manage trident/tomahawk switches? Nope.
brcm sdk is still necessary.
nexthop objects are essential to configure enterprise switches.
Clearly cumulus customers don't like iproute2 style because it's missing
this feature, so David's proposal is to add that to the kernel.
Even after kernel and iproute2 understand nexthop id the kernel is still
not going to be competitive with switching os. The linux kernel is an OS
to run on the host cpu and to run on a control plane cpu of a switch.
That is all great, but the reasons to push routing into the kernel
of control plane cpu were weak. It's not using these routes.
Such architecture allowed temporary reuse of bgp daemons, but it fails to scale.
No need to push route to the kernel when kernel won't use them.
Hence an alternative proposal:
- introduce hooks at netlink layer and steal back and forth messages
from your favorite daemon without populating the kernel
- same for iproute2 netlink interaction