I think I remember to fix ssdp you brought some of route cache and igmp
back. 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.

I'm OK to test this scenario.

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
>