Open Stack

[Sorry for the resend, I had to subscribe to openstack-dev first,
 maybe worth removing the subscribe requirement for outsiders]

[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.