On Wed, 17 Jan 2001, James R. Leu wrote:
> Remember that routing/switching vendors have a hardware fast path. The
> signalling or routing protocol packets are the only traffic that go to the
> route/switch processor. Protocol developers look for features of the IP
> stack not neccessarily speed. If the IP stack doesn't provide enough features
> why use it?
>
So what kind of features would you be looking for? I take it this is still
related to netlink and the unreliability?
>If an IP routing stack running on Linux ever hopes to achieve sub 50ms
>end-to-end re-routing with 80K routes and 16K interface, netlink will
>have to guarantee reliable, incremental and timely updates. If netlink
>cannot do it, routing software developers will either look to another
>operating system that can provide this, or will completely by-pass the
>Linux IP stack and relegate Linux to be an embedded trampoline for them
>to run there own IP stack in user land.
This sounds a bit strong. Netlink happens to document that messages can
be lost. Route sockets in BSD which are used by quiet a few router vendors
out there albeit for years now, i suppose do not make this obvious. If you
have a fifo socket receive queue which fills up at some point; wouldnt you
expect that BSD sockets also would drop those messages? Unless you have
infinite memory, how is this different from Linux netlink as far as
"unreliability" is concerned?
> I still assert that netlink's requirement for a client to re-read the
> entire interface or routing table to maintain synchronization is a hack.
I think it's a design tradeoff. Under a really heavy load, if you can
detect this, say by seeing the first ENOBUFS, polling is a _better_
solution. Latency is a non-issue since you are gonna be loosing a lot of
those messages. Under low load, latency becomes important, so async
notification makes sense,
Your mileage may vary, but if you make your app capable of this, it
becomes more robust.
cheers,
jamal
|