On 8/13/19 2:51 PM, Cybertinus wrote:
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 :)
Of course. After we fix a stupid bug in 2.0.5, it should also yield faster filters.
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.
You can use a dirty hack, run one multithreaded BIRD for filtering and another BIRD at the same machine for route export to kernel, connected locally by a BGP session.
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?
I'll keep this mailing list updated as we need people to test it. Parallel execution of legacy code is always a can of worms ... a truck full of cans of worms. Maria