[Babel-users] Ability to work with massive number of routes? (global full-table)

[Dave Taht]

On Tue, Sep 25, 2018 at 6:48 AM Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>
> Dave Taht <dave.taht at gmail.com> writes:
>
> > And - setting a goal for 64k routes - I thought that switching to a
> > normalized table structure internally would be useful. Instead of
> > storing the nexthop as a full address store an 16 bit index pointing
> > to an array of those nexthops. And so on.
>
> Incidentally, it looks like the Linux kernel will start doing this as
> well:
>
> https://marc.info/?l=linux-netdev&m=153576423232067&w=2

Yea! But:

"The difference between real and system times shows there is room for
improvement with the trie implementation. As an example, increasing the
sync_pages from 128 to 1024 delays the call to synchronize_rcu increasing
the insert rate to more than 78,000 prefixes/sec!"

One of the reasons why I harp on the need to get rid of the del/add
non-atomic behavior in babeld
is that route manipulation behavior in Linux has been increasingly
tied to rcu'd behavior, and the odds
of being caught out the outskirts of that cycle have gone up
considerably. I used to be able to routinely
get no route icmp messages back along the path while doing flent
testing at 100s of mbits during those
brief windows, during routine updates, back when my network had a few
hundred routes. While that "helps"
in terms of circuit breaker congestion control, its... suboptimal.

'course there's still trying to get the old channel awareness code to
work again also...

and merging the 3+ different branches

and...

sometimes it doesn't pay to get up at 3AM to fix a broken router.

> -Toke



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619