[ovs-dev] OVN: Possible scalability bottleneck around the port binding table

Liran Schour LIRANS at il.ibm.com
Tue Aug 25 19:10:02 UTC 2015

Ben Pfaff <blp at nicira.com> wrote on 25/08/2015 06:17:22 PM:

> From: Ben Pfaff <blp at nicira.com>
> To: Liran Schour/Haifa/IBM at IBMIL
> Cc: dev <dev at openvswitch.org>
> Date: 25/08/2015 06:18 PM
> Subject: Re: [ovs-dev] OVN: Possible scalability bottleneck around 
> the port binding table
> On Tue, Aug 25, 2015 at 11:46:36AM +0300, Liran Schour wrote:
> > Proposed solutions: both options are based on allowing the vSwitch 
> > (ovn-controller) to monitor only a subset of the port binding table. 
> > can think about it as a compromise between the fully pro-active and 
> > re-active approaches (push vs. pull).
> > 
> > Option 1: Extend OVSDB protocol to include a new method to allow the 
> > client to monitor a table under a specific condition and being updated 

> > only on rows that satisfy the condition ( e.g "datapath"== XYZ ). This 

> > will allow each vSwitch in OVN to monitor only a subset of the logical 

> > datapaths.
> Yes, this makes sense, and it is already on the to-do list.
> *** Reducing amount of data sent to clients.
>     Currently, whenever a row monitored by a client changes,
>     ovsdb-server sends the client every monitored column in the row,
>     even if only one column changes.  It might be valuable to reduce
>     this only to the columns that changes.
>     Also, whenever a column changes, ovsdb-server sends the entire
>     contents of the column.  It might be valuable, for columns that
>     are sets or maps, to send only added or removed values or
>     key-values pairs.
>     Currently, clients monitor the entire contents of a table.  It
>     might make sense to allow clients to monitor only rows that
>     satisfy specific criteria, e.g. to allow an ovn-controller to
>     receive only Logical_Flow rows for logical networks on its 

Good, I will write RFC for the new OVSDB monitor method for approval 
before starting to implement this..

- Liran

More information about the dev mailing list