[Babel-users] the routing atomic update wet paint - because *I* care

[Dave Taht]

On Tue, Apr 7, 2015 at 6:35 AM, Henning Rogge <hrogge at gmail.com> wrote:
> On Tue, Apr 7, 2015 at 3:19 PM, Matthieu Boutier
> <boutier at pps.univ-paris-diderot.fr> wrote:
>>> If you work with atomic route replacement even putting ALL of them
>>> into a netlink message (or as many as you can fit in) works.
>>
>> What I understand is that we can't (in general) work with atomic
>> *next-hop* replacement (interface index and metric may change).
>
> Interface index is not a problem... metric-change is.

I am sorry, I do not understand, once again.

>> I proposed a workaround where instead of using two distinct messages
>> for "del(r)" and "add(r)" we use one message with "del(r); add(r)".
>> Even if it's not necessarily atomic (is it?), it should be faster
>> (only one system call, since it was what frightened Dave).

It was the changes to do RCU in the new FIB routing code that
"frightened" me. RCU runs asynchronously.

There is also the ongoing work to use these APIs to reprogram
(open)switch hardware.

All I can do is test, and measure, on the gear I got, on the upcoming kernels.

>
> Henning



-- 
Dave Täht
We CAN make better hardware, ourselves, beat bufferbloat, and take
back control of the edge of the internet! If we work together, on
making it:

https://www.kickstarter.com/projects/onetswitch/onetswitch-open-source-hardware-for-networking