Re: [Cerowrt-devel] atomic route updates?

[Dave Taht <dave.taht@gmail.com>]

On Tue, Apr 23, 2013 at 11:14 PM, Maciej Soltysiak <maciej@soltysiak.com> wrote:
> I think I remember to fix ssdp you brought some of route cache and igmp
> back.

No. What I did observe was that for the past 2+ years, routing
behavior kept changing in subtle ways, and I am hoping it's all
perfect now.

the igmp bug was due to openwrt being too agressive on removing
useless cruft from /proc, thus breaking a few userspace tools. Been
fixed a while now.

> Do we know if cero routed setup without route cache can work with
> ssdp? I wouldn't like to force bringing back route cache just for ssdp.

Routes are routes. The route cache was an inefficient means of
theoretically speeding up route lookup and has been eliminated, that's
all. Route lookups still happen, just not through an over-abstracted
cache mechanism.

> I'm OK to test this scenario.

goferit.

>
> Maciej
>
> On 20 Apr 2013 18:01, "Dave Taht" <dave.taht@gmail.com> wrote:
>>
>> iproute2's ip/iproute2.c code has a function called iproute_modify,
>> which to a blurring eye appears to be capable of doing an atomic route
>> update via it's netlink interface.
>>
>> "        if (matches(*argv, "change") == 0 || strcmp(*argv, "chg") == 0)
>>                 return iproute_modify(RTM_NEWROUTE, NLM_F_REPLACE,
>>                                       argc-1, argv+1);
>>         if (matches(*argv, "replace") == 0)
>>                 return iproute_modify(RTM_NEWROUTE,
>> NLM_F_CREATE|NLM_F_REPLACE,
>>                                       argc-1, argv+1);"
>>
>> The babel  native daemon and the quagga-re code, however, does a
>> delete/add, which results in packets dropping on the floor when a
>> route changes.
>>
>> Everyone that's tried to make this code do atomic updates has failed.
>>
>> Juliusz thinks this section of the codebase is cursed, and I
>> personally, gave up, because dave miller had spent most of the last 3+
>> years eliminating the linux kernel route cache, (which was finally
>> eliminated a few kernel versions back (3.6?)) and I figured all
>> attempts at doing anything fancy with routing during that phase was
>> going to break in odd ways until the new cache-free-linux-kernel
>> routing code stabilized.
>>
>> OK, so, like, it's kernel 3.8 time now, and ...  I find myself too
>> scarred by previous attempts to give it a go myself, but I know that
>> out there are intrepid explorers out there, just dying to delve into
>> the gnarly details of netlink programming to keep a few more streams
>> going full throttle in the face of a routing change! Yes? Anyone? So
>> take a look at iproute2 and the relevant netlink code here:
>>
>> git://github.com/Quagga-RE/quagga-RE.git
>> git://github.com/jech/babeld.git
>>
>> I note that I have a few other ideas for netlink-related changes to
>> cero. Two of the big ones is that I'd like to be able to have a
>> userspace daemon get back more details as to when *fq_codel drops a
>> packet (e.g, send a multicast to a listener of the dropped the packet,
>> and why), and get some sort of ongoing bandwidth estimate when it
>> starts dropping, etc.
>>
>> I also have some hope for multi-prefix multi-homed routing too...
>>
>> but I find netlink really intimidating. It has an interface that only
>> a bit-banger would love.
>>
>> --
>> Dave Täht
>>
>> PS: I have a build of 3.8.8 at the moment that uses the new PROCD
>> replacement for init that I'm losing a battle on, too. Also toke has
>> got cero mostly independently buildable now.
>>
>> Fixing bufferbloat with cerowrt:
>> http://www.teklibre.com/cerowrt/subscribe.html
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html