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 <[email protected]> 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 > -- Douglas Fernando Fischer Engº de Controle e Automação
