This is very interesting news! Can you tell me more about this (maybe in a separate thread, to not pollute this one)? first few questions I do have:
Changing the subject, it should be enough.
1. Will this be done only in the 2.x branch, or also in the 1.6.x?
Only in 2.x; these changes include sh*tload of changes in route propagation which we won't do twice.
2. If you do use the Kernel protocol, is the entire Bird process still single threaded, or only the part regarding the Kernel protocol? So, calculating which route is best could still be multi threaded, but sending the end result to the kernel is single threaded
The multithreaded BIRD will be in a separate code branch, a separate version, separate binary. If you opt for multithreaded, no kernel protocol will be available at all.
3. If you do use the Kernel protocol to send routes to the kernel, is there any alternative to get Bird fully multi threaded?
To wait until we rework the kernel-nest interface; then we'll merge multithreaded execution into master.
I run Bird on 4 routers, most of them have 8 cores, one of them even has 12 cores, so I would love to be able to use all those cores for Bird! And I could even double the amount of cores if I would enable Hyper Threading again, but from a security point of view I don't want to do that.
At least if you have some non-trivial filters, it will help you. The first code to be multithreaded is filter code, then probably other parts will follow. Maria