On Tue, Sep 25, 2018 at 6:48 AM Toke Høiland-Jørgensen <[email protected]> wrote: > > Dave Taht <[email protected]> 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 _______________________________________________ Babel-users mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
