[ovs-dev] [PATCH monitor_cond V10] RFC OVN: Implementation of conditional monitoring usage

[Mickey Spiegel]

-----Liran Schour/Haifa/IBM wrote: -----

>To: Mickey Spiegel/San Jose/IBM at IBMUS
>From: Liran Schour/Haifa/IBM
>Date: 07/21/2016 04:18AM
>Cc: Ben Pfaff <blp at ovn.org>, dev at openvswitch.org
>Subject: Re: [ovs-dev] [PATCH monitor_cond V10] RFC OVN:
>Implementation of conditional monitoring usage
>
>Mickey Spiegel/San Jose/IBM wrote on 20/07/2016 08:53:42 AM:
>
>> From: Mickey Spiegel/San Jose/IBM
>> To: Liran Schour/Haifa/IBM at IBMIL
>> Cc: Ben Pfaff <blp at ovn.org>, dev at openvswitch.org
>> Date: 20/07/2016 08:53 AM
>> Subject: Re: [ovs-dev] [PATCH monitor_cond V10] RFC OVN: 
>> Implementation of conditional monitoring usage
>> 
>> Comments inline as <Mickey>
>> 
>> -----"dev" <dev-bounces at openvswitch.org> wrote: -----
>> To: Ben Pfaff <blp at ovn.org>
>> From: Liran Schour 
>> Sent by: "dev" 
>> Date: 07/19/2016 01:45AM
>> Cc: dev at openvswitch.org
>> Subject: [ovs-dev] [PATCH monitor_cond V10] RFC OVN: Implementation
>> of conditional monitoring usage
>
>> Conditional monitor of: Port_Binding, Logical_Flow, Multicast_Group
>> MAC_Binding tables. As a result ovn-controller will be notified only about
>> records belongs to a datapath that is being served by this hypervisor.
>> 
>> Performance evaluation:
>> OVN is the main candidate for conditional monitoring usage. It is clear that
>> conditional monitoring reduces computation on the ovn-controller (client) side
>> due to the reduced size of flow tables and update messages. Performance
>> evaluation shows up to 75% computation reduction.
>> However, performance evaluation shows also a reduction in 
>> computation on the SB
>> ovsdb-server side proportional to the degree that each logical network is
>> spread over physical hosts in the DC. Evaluation shows that in a realistic
>> scenarios there is a computation reduction also in the server side.
>> 
>> <Mickey> Before getting into details, please confirm whether I have
>> a proper understanding how this works:
>> When a hypervisor first comes up, it gets no port bindings.
>> When a VIF comes up on the hypervisor, this will trigger filter_port
>> on that VIF, which causes the port binding for that VIF to come down
>> to the controller.
>> Upon receipt of that port binding, the controller will add the 
>> datapath for the VIF's logical switch to local datapaths, which will
>> trigger filter_datapath.
>> This will cause all of the port bindings, MAC bindings, logical 
>> flows, and multicast groups for the VIF's logical switch to come 
>> down to the controller.
>> Following the patch ports from the VIF's logical switch, this will 
>> trigger filter_port for all peer patch ports.
>> The port bindings for those peer patch ports will trigger 
>> filter_datapath for all logical router datapaths connected to the 
>> logical switch.
>> This will cause all of the port bindings, MAC bindings, logical 
>> flows, and multicast groups for those datapaths to come down to the
>> controller.
>> If those datapaths have patch ports to additional datapaths, 
>> following the patch ports, eventually all of the SB info for all 
>> connected datapaths will come down to the controller.
>> Is this correct?
>> 
>
>Yes. One small addition: to minimize the number of filters, the code
>will unfilter_lport when the lport is already included in a flittered
>datapath.

All of this is far from obvious. It would be good to document this in ovn-architecture.7.xml.

Mickey