On Mon, Apr 6, 2015 at 7:22 PM, Dave Taht <dave.t...@gmail.com> wrote: > 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.
Strange... I definitely had some (ipv6) cases which ran fine with the new kernel but badly with the old one. > 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) I don't even think the API is bad... its just badly documented. And libnl(1/2/3?) was painful enough that I decided not to use it at all for olsrd2. > 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. olsrd2 ist a common linkstate protocol... it collects all the information about the links and runs a dijkstra on them... then use the result to setup the new version of the routes. The whole process runs asynchronous, I don't wait for the kernel return codes, I just setup all the necessary changes and then parse the netlink feedback later. Henning _______________________________________________ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users