Well, I tried the patches and they did not work (as expected), but I think we are closer. I will try to create some test cases using ip route to do what I want, and get back to folk when I have time. I have a ton of other reasons to want to grok the netlink code more deeply.
I note that I called this thread "wet paint" - It was sunday, I had nothing to do but watch benchmarks run - I would like atomic updates to work. I keep poking at it as to why it doesn't. I do not know if it is a common meme outside the US to see a sign that says "wet paint" and to go touch it, to make sure. The ongoing FIB tree rework going into linux 4.0 and 4.1 struck me as a starting point to improve the kernel API (if needed), if we can´t find a way to make it work better. I am NOT pressuring to get it in any user space routing code presently! What I am trying to do is figure out how to fix the kernel (if needed), or do it more right in the routing daemons. (and by jove if we need kernel mods, there be an API to figure out if a newer API is available) Linux TCP has sprouted the ability to handle massive re-ordering (order, megabytes) and there has been a ton of work on things like QUIC that are also highly tolerant, as well as things like torrent, which already handle it. Babel (dont know about OLSR) finds a "usable" path, then tunes to a better one, but each tuning step (particularly at high rates) can lose packets, which cause rate reductions. Ideally would like to never lose packets while tuning happens. The most common case where I see an interruption in flows is when I go back from a wlan to an ethernet, under load, so being able to modify a route atomically to switch devices on the route was my end goal. The simple test I came up with earlier in the thread was not, but seemed useful. _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
