On 13.03.2012 18:39, Martin Mares wrote:
Hello!
This can help CLI interaction (and it is good as temporary solution),
but does not decrease time needed for dispatching flapping sessions
(particularly if there are many of them).
If you introduce priorities in the event loop, you can make sure that
flapping sessions cannot disrupt other sessions.
Well, I'm talking mostly not about flapping, bird seems to behave quite
well. I mean, sometimes it matters if, say, reflector with several
hundred BGP sessions can take them all up from random states within 1
(but not 2 or 3 or 4) minutes and continue to work "normally" if half of
them is flapping. (And here kernel syncer steps in and says "hey, I need
half of your CPU"). From this point of view any priorities (if I get an
idea correctly) won't help.
I already thought about event priorities when I wrote the event loop,
but I finally chose simplicity and decided that priorities can be added
later if it turns out that they are needed.
Offloading some activity with low core interaction to another thread can
be a good start for offloading another parts of code (protocol messages
parsing, sending hello messages, etc..).
I think that once we decide that we need threading, it's better to
do it once and well. I thought about it some years ago and it seems
it won't be too complicated.
Can you briefly describe it? I thought about this too, but,
unfortunately, I can't see the way which does not imply significant core
complication.
Moreover, this approach can improve the situation with kernel scan
Wouldn't it be better to get rid of kernel scans completely? :-)
Personally I like an idea of having additional independent
self-healing/controlling process. Disabling it (which is already
available) is one of possible solutions, but..
I think they should not be needed on current Linux systems, they are
there only to make sure that no Netlink packets with updates got dropped.
Have a nice fortnight
--
WBR, Alexander
