This is very good news!

I know you said "This is a ball park guess", but I confess that I was a little scared by the proportion of extra CPU usage (30/48 -> +60%).
I also know that you said that the code is still "currently not releasable", but I'm curious to know a little more about how this multi-threading was handled.


Just to illustrate:

Single-Core CPU on BGP is known to be a problem for many engines and vendors.

One of the vendors developed a "creative" way to do this load distribution in multiple colors.
As I understood it, they made a kind of Affinity CPU by BGP-Peer.
In a way that each peer has a BGP process, and that process is "semi-tied" to a core.
And they created a mechanism to redistribute these affinities from time-to-time based on the amount of BGP messages per second exchanged on each peer.

Em ter., 2 de mar. de 2021 às 10:13, Maria Matejka <maria.matejka@nic.cz> escreveu:

Hi!

On 3/1/21 1:26 PM, Marcelo Balbinot wrote:
>
> Hi, I already asked this question at some point,
> but I am curious about the evolution ..
> About multi thread support (multi-core cpu use).
> Is this still a possibility?

Yes, it is. Be prepared that this will also raise memory usage (current
estimates are about >+10% memory) and overall CPU usage (compared to
single-thread execution) due to needed synchronization and buffers.

This means that if you now consume 20G of memory and 30 minutes of
single core time to converge the main table on a rather big node, you're
going to consume, let's say, >22G of memory and 3 minutes of 16-core CPU
(summing to 48 minutes of CPU time). This is a ball park guess, do not
take me much seriously. It may be better, it may be worse.

Anyway, there is some code (currently not releasable) that will get to a
preview release soon. We'll highly appreciate testing from any user
around. Stay tunad!

Maria