On Tue, Dec 4, 2018 at 2:52 PM Christof Schulze <[email protected]> wrote: > > Juliusz, > > >I'd need to read up on data structures, as I don't currently understand > >the tradeoffs between binary heaps and timer wheels. (Same goes for > >dealing with resends. And Christof suggested that we should modify the > >main event loop in babeld to use a proper data structure.) > > * Implement a generic task scheduler that could shamelessly be borrowed > from fastd or l3roamd and then modified to use whatever datastructure > being helpful to increase efficiency. In any case it looks to me as if > an abstraction layer could be helpful.
> * Given that babeld will be used in scenarios with many more interfaces > than before it could be worth moving from select to epoll. This would > also allow moving the FD_SET construction out of the loop. epoll is not available in bsd. the equivalent is kqueue. https://libevent.org/ wraps various mechanisms. > The first point specifically will help in structuring the loop. The > second will get rid of overhead in the kernel and allow us to move the > setup of the fd outside. My nemeses are C & mips. It was good to learn from markus on these threads that golang finally worked on mips! Having mips as my primary platform for a decade has stopped me from picking up a more modern language like go, and I dearly miss associative arrays, green threads, and the like. I am considering go for another project and the netlink support in go has improved enormously since las I looked ( https://medium.com/@mdlayher/linux-netlink-and-go-part-2-generic-netlink-833bce516400 ) That said, I don't feel a go version of babel adds much to the party, and that it would be better to focus on making babeld better - finishing up hmac and dtls, fixing stuff like the broken wifi channel detection, improving error handling and scaling performance. I'm pretty convinced that hashing route lookups and using an abstract route type will make a difference (thought experiment: a binary search of 2048 34 byte routes will take ~11 probes, a hash, ~3 - processing a packet of 50 routes will touch ~1000 32 byte cache lines, wiping out a 32k dcache completely - but that's just packet processing, there's resends and conflict resolution, filtering and disambiguation - some of which do need insight into the actual route) memory pools are easy to add to C, and helpful for reducing fragmentation and gleaning statistics on memory use patterns, babel's design is amiable to that with very few malloc/free pairs and < 10 main data structures. With a memory pool to start with... well... as much as I initially liked the "dev" branch's API, I'm leaning towards that abstract (int) route type, and instead of trying to fit source specific, ipv4, ipv6 routes into a single 34 byte structure, to stick them into a right-sized structure for each type. choosing a memory pool design... a hash function... a hash table design... in c... is my current sticking point in that other project also (and why I yearn for go!) Oy, a lot of work! > > > [1] https://github.com/freifunk-gluon/l3roamd/blob/master/src/taskqueue.c > > viele Grüße > > Christof > > > > -- > () ascii ribbon campaign - against html e-mail > /\ against proprietary attachments > > _______________________________________________ > Babel-users mailing list > [email protected] > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users -- 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
