-----Liran Schour/Haifa/IBM wrote: ----- >To: Mickey Spiegel/San Jose/IBM@IBMUS >From: Liran Schour/Haifa/IBM >Date: 07/21/2016 04:18AM >Cc: Ben Pfaff <b...@ovn.org>, dev@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@IBMIL >> Cc: Ben Pfaff <b...@ovn.org>, dev@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-boun...@openvswitch.org> wrote: ----- >> To: Ben Pfaff <b...@ovn.org> >> From: Liran Schour >> Sent by: "dev" >> Date: 07/19/2016 01:45AM >> Cc: dev@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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
