Re: [PATCH RFC net-next 00/18] net: Improve route scalability via support for nexthop objects

2018-09-04 Thread David Ahern
On 9/2/18 11:34 AM, David Miller wrote:
> From: dsah...@kernel.org
> Date: Fri, 31 Aug 2018 17:49:35 -0700
> 
>> Examples
>> 1. Single path
>> $ ip nexthop add id 1 via 10.99.1.2 dev veth1
>> $ ip route add 10.1.1.0/24 nhid 1
>>
>> $ ip next ls
>> id 1 via 10.99.1.2 src 10.99.1.1 dev veth1 scope link
>>
>> $ ip ro ls
>> 10.1.1.0/24 nhid 1 scope link
>> ...
> 
> First of all, this whole idea is awesome!  But, you knew that already. :)

:-)

> 
> However, I worry what happesn in a mixed environment where we have routing
> daemons and tools inserting nexthop based routes, and some doing things
> the old way using and expecting inline nexthop information in the routes.
> 
> That mixed environment situation has to function correctly.  Older
> apps have to see the per-route nexthop info in the format and layout
> they expect (gw/dev pairs).  They cannot be expected to just studdenly
> understand the nexthop ID etc.
> 
> Otherwise the concept and ideas are fine, so as long as you can resolve
> the mixed environment situation I fully support this work and look forward
> to it being in a state where I can integrate it :-)
> 

RTA_NH_ID is on par with other new attributes (RTA_ENCAP for example) --
userspace apps get a route attribute and have no idea what it means
until support is added (e.g., it took more than 2 years for libnl to get
support for RTA_ENCAP). I take your comment to mean you prefer this new
attribute to be treated differently -- assume apps are clueless unless
they indicate otherwise. Given the number of ioctl based apps that might
be the better option for this case.

I can add an attribute for apps to specify 'hey, I understand nexthops'
on dump and get requests (per-app flag), and then I can add a sysctl
that controls whether the nexthop spec is included. The sysctl would be
for notifications and a global option for dumps/gets. Users who know
their OS is safe for the short form can set it and get the benefit of
smaller messages. While the biggest win here is pushing routes to the
kernel faster, there is also a gain with less data from the kernel in
route dumps and notifications, especially with multipath environments.


Re: [PATCH RFC net-next 00/18] net: Improve route scalability via support for nexthop objects

2018-09-02 Thread David Miller
From: dsah...@kernel.org
Date: Fri, 31 Aug 2018 17:49:35 -0700

> Examples
> 1. Single path
> $ ip nexthop add id 1 via 10.99.1.2 dev veth1
> $ ip route add 10.1.1.0/24 nhid 1
> 
> $ ip next ls
> id 1 via 10.99.1.2 src 10.99.1.1 dev veth1 scope link
> 
> $ ip ro ls
> 10.1.1.0/24 nhid 1 scope link
> ...

First of all, this whole idea is awesome!  But, you knew that already. :)

However, I worry what happesn in a mixed environment where we have routing
daemons and tools inserting nexthop based routes, and some doing things
the old way using and expecting inline nexthop information in the routes.

That mixed environment situation has to function correctly.  Older
apps have to see the per-route nexthop info in the format and layout
they expect (gw/dev pairs).  They cannot be expected to just studdenly
understand the nexthop ID etc.

Otherwise the concept and ideas are fine, so as long as you can resolve
the mixed environment situation I fully support this work and look forward
to it being in a state where I can integrate it :-)