[Copying ovs-dev] On 02/13/15 at 01:47pm, Miguel Ángel Ajo wrote: > Sorry, I forgot about > > 5) If we put all our OVS/OF bridge logic in just one bridge (instead of N: > br-tun, br-int, br-ex, br-xxx), > the performance should be yet higher, since, as far as I understood, > flow rule lookup could be more > optimized into the kernel megaflows without forwarding and re-starting > evaluation due to patch ports. > (Please correct me here where I’m wrong, I just have very high level > view of this).
Some preliminary numbers were presented at the OVS Fall Conference 2014 which indicate that a pure OVS ACL solution scales better as the number of rules changes. You can find the number on slide 9 here: http://www.openvswitch.org/support/ovscon2014/17/1030-conntrack_nat.pdf Another obvious advantage is that since we have to go through the OVS flow table anyway, traversing any additional (linear) ruleset is likely to have more overhead. FYI: Ivar (CCed) is also working on collecting numbers to compare both architectures to kick of a discussion at the next summit. Ivar, can you link to the talk proposal? > On Friday, 13 de February de 2015 at 13:42, Miguel Ángel Ajo wrote: > > > I’m working on the following items: > > > > 1) Doing Openflow traffic filtering (stateful firewall) based on OVS+CT[1] > > patch, which may > > eventually merge. Here I want to build a good amount of benchmarks to > > be able to compare > > the current network iptables+LB solution to just openflow. > > > > Openflow filtering should be fast, as it’s quite smart at using hashes > > to match OF rules > > in the kernel megaflows (thanks Jiri & T.Graf for explaining me this) > > > > The only bad part is that we would have to dynamically change more > > rules based on security > > group changes (now we do that via ip sets without reloading all the rules). Worth pointing out that it is entirely possible to integrate ipset with OVS in the datapath in case representing ipsets with individual wildcard flows is not sufficient. I guess we'll know when we have more numbers. > > To do this properly, we may want to make the OVS plugin a real OF > > controller to be able to > > push OF rules to the bridge without the need of calling ovs-ofctl on the > > command line all the time. We should synchronize this effort with the OVN effort. There is a lot of overlap. > > 2) Using OVS+OF to do QoS > > > > other interesting stuff to look at: > > > > 3) Doing routing in OF too, thanks to the NAT capabilities of having OVS+CT > > Just want to point out that this is still WIP with several issues outstanding. I think everybody agrees that it's tremendously useful to have, we need to be able to implement it properly. I'll let you and anybody else interested know as soon as it's ready for testing. > > 4) The namespace problem, what kinds of statistics get broken by moving > > ports into namespaces now?, > > the short-term fix could be using vets, but “namespaceable” OVS ports > > would be perfect, yet I understand > > the change is a big feature. > > > > If we had 1 & 3, may be 4 wouldn’t be a problem anymore. Implementing VRF in OVS will hide (4) for OpenStack but we should still fix it in OVS as Ben suggested in the Bugzilla. It looks feasible to support netns properly in OVS. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
