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