Yea! I'll look (this weekend). My babeld-atomic branch (which currently just calls the ip route command) is still working well but I haven't had a chance to try it against an interface switch yet. Net reduction in netlink commands of ~40%, but in many cases, further up the babel stack, when it optimizes a route, it still does an del/add rather than a replace.
I did a bit more poking into the bitwise trie idea - the original research and set of optimizations were against ipv4 prefixes, not really against ipv6, and certainly not against a source specific routing protocol, but still seems quite promising. dlmalloc uses essentially the same concept internally, also. I'd love to shoot for 2m routes.... should be enough to last the next decade... (famous last words) aside: popcount is now a readily available and cheap single instruction on most x86 arches. I was originally thinking it as a way of shortening otherwise rather deep rbtrees, (and I've mostly discarded that idea but it looked promising for things like set difference) but you do lose the "within" characteristic. Can't wait to switch over to the new ss support! And - ooh! unicast! fun! On 10/25/18, Juliusz Chroboczek <[email protected]> wrote: >> struct babel_addrs { // could use a better name >> unsigned char src_prefix[16] >> unsigned char prefix[16]; >> unsigned char src_plen; >> unsigned char plen; >> unsigned short nexthop; // an index, not a ptr, into the nexthop >> table, sometimes unused >> }; > >> struct resend *find_request(const struct babel_addrs *, struct resend >> **previous_return); > > See the "dev" branch in Matthieu's fork of babeld -- he's calling that > "struct datum". > > -- Juliusz > -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 _______________________________________________ Babel-users mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
