On 2019-08-13 13:08, Maria Jan Matejka wrote:
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.
Right, makes sense indeed. Then I have to upgrade from 1.6 to 2.0 :)
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.
OK, that's a clear and conscious decision for the users then indeed.
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.
OK, then I have to wait for that, because I do use the Kernel protocol
to place the best routes from all my peers into the kernel routing
table.
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.
I filter a lot. Currently my Bird config is 78 MB in size, most of it is
filtering. That should be noticeable then.
Thanks for your answers. Is there some easy way to follow the process
for this, apart from regularly check out the git repo and reading
through the commit messages?
Maria
Kind regards,
Cybertinus
