> 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
smime.p7s
Description: S/MIME Cryptographic Signature
