[Babel-users] Babeld news

[Dave Taht]

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 <jch at irif.fr> 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