On Mon, Jul 18, 2016 at 10:32:29AM -0500, Ryan Moats wrote: > "dev" <dev-boun...@openvswitch.org> wrote on 07/11/2016 02:59:29 AM: > > > From: Zong Kai LI <zealo...@gmail.com> > > To: dev@openvswitch.org > > Date: 07/11/2016 02:59 AM > > Subject: [ovs-dev] [PATCH] [Patch v1] ovn-controller: ignore lflow > > matching remote VM port > > Sent by: "dev" <dev-boun...@openvswitch.org> > > > > Currently, ovn-controller will install all lflows for a logical > > switch, when ovn-controller determines not to skip processing of > > that logical switch. > > > > This will install too many OVS flows. We have 11 tables for logical > > switch ingress pipeline, 8 tables for logical switch egress pipeline > > now, and more in futrue. > > > > There are two kind lflows in for logical switch. One has no > > inport/outport matching, such as lflows in table ls_in_arp_rsp and > > ls_in_l2_lkup. The other one has, and for now, lflows in the following > > tables belong to this type: > > - ls_in_port_sec_l2 > > - ls_in_port_sec_ip > > - ls_in_port_sec_nd > > - ls_in_pre_acl > > - ls_in_acl > > - ls_out_pre_acl > > - ls_out_acl > > - ls_out_port_sec_ip > > - ls_out_port_sec_l2 > > > > Consider how packet trip through flows in network topology > > (P: port, S: switch, R: router. > > Two VM(or VIF) ports are on different chassis): > > - P-S-P: only flows matching remote inport, local VM port as "inport" > and > > local VM port as "outport" will be matched. There is no chance > for > > flows matching remote VM port as "inport" or "outport" to > > be matched. > > - P-S-R-S-P and P-S-R...R-S-P: all these cases seem different from the > > above one, but they have the same "last jump". No matter how > > many routers(with or without switches) are used, before packet > > leaves current chassis, the next jump will be: > > destination_switch_gateway -> destination_switch_port, > > so it will become a P-S-P case again. > > And sinse this patch will not change ingress pipeline for > > logical routers, so traffic between router port to router port > > will not be impacted. > > So, as we can see, we don't need to install flow for a lflow with inport > > or outport matching in logical switch ingress pipeline, when it tries to > match > > a VM(or VIF) port that doesn't belong to current chassis. > > This can help ovn-controller to avoid to install many unnecessary flows. > > > > The following data are flows number comparison on a 2 chassis > environment, > > with 7 VMs(4 VMs on chassis-1(ch1), 3 VMs on chassis-2(ch2)), 3 dnsmasq > > interfaces(on chassis-1), and some lsp-lrp pairs: > > > > +-------------------+---------------+-------------+-------------+ > > |number of flows in | upstream-code | this patch | this patch | > > |table | | works on ch1| works on ch2| > > +-------------------+---------------+-------------+-------------+ > > |ls_in_port_sec_l2 | 37 | 34 | 30 | > > |ls_in_port_sec_ip | 114 | 91 | 81 | > > |ls_in_port_sec_nd | 70 | 44 | 32 | > > |ls_in_pre_acl | 26 | 26 | 26 | > > |ls_in_acl | 71 | 53 | 47 | > > |ls_out_pre_acl | 30 | 30 | 30 | > > |ls_out_acl | 157 | 100 | 82 | > > |ls_out_port_sec_ip | 57 | 35 | 26 | > > |ls_out_port_sec_l2 | 18 | 15 | 11 | > > +-------------------+---------------+-------------+-------------+ > > |total | 580 | 428 | 365 | > > +-------------------+---------------+-------------+-------------+ > > |reduce ls flows | -- | 26% | 37% | > > +-------------------+---------------+-------------+-------------+ > > |all chassis flows | 767 | 627 | 552 | > > +-------------------+---------------+-------------+-------------+ > > |reduce totally | -- | 18% | 28% | > > +-------------------+---------------+-------------+-------------+ > > > > Image such a topology, 10 chassis, and 50 VMs/chassis. Let's take table > > ls_in_port_sec_l2 as example, with some constant flows, current > > implement will install 500 + C flows in ls_in_port_sec_l2 on each > > chassis. After we ignore lflows matching remote VM inport, it will have > > 50 + C flows been installed in table ls_in_port_sec_l2 on each node. > > > > Signed-off-by: Zong Kai LI <zealo...@gmail.com> > > This helps me get closer, but I'm still slightly uncomfortable with > how this will work if an instance moves from one chassis to another > (i.e. when a port unbinds from one chassis and binds to another > chassis)...
Well, presumably the flows need to be reconsidered at that point. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
