[ovs-dev] [PATCH] ovsdb: provide raft and command interfaces with priority

Anton Ivanov anton.ivanov at cambridgegreys.com
Fri Jun 11 06:05:08 UTC 2021

On 10/06/2021 23:01, Ben Pfaff wrote:
> On Tue, Jun 08, 2021 at 10:27:08AM +0100, anton.ivanov at cambridgegreys.com wrote:
>> From: Anton Ivanov <anton.ivanov at cambridgegreys.com>
>> Set a soft time limit of "raft election timer"/2 on ovsdb
>> processing.
>> This improves behaviour in large heavily loaded clusters.
>> While it cannot fully eliminate spurious raft elections
>> under heavy load, it significantly decreases their number.
>> TODO: randomize session processing order to ensure individual
>> sessions towards the end of the remotes list are not starved
>> Signed-off-by: Anton Ivanov <anton.ivanov at cambridgegreys.com>
> Personally I'd consider a random or round-robin processing order to be
> pretty critical here.

I agree.

I will send a revised patch with either round-robin or "restart where it 

> A better approach (which would be a lot more work) would be for the Raft
> code to use a separate thread or process.

Looked at that from several angles. Not realistic without a complete 

1. The amount of locking needed will be severely detrimental to 
performance. I tried at some point to play with putting all monitors 
processing into a parallel pool and it needed on the order of 4-5 
mutexes per monitor protecting different parts of it. Storage is likely 
to be even worse.

2. It will end up pushing storage state that does not correspond to a 
complete transaction which is a can of worms in its own right.


Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661

More information about the dev mailing list