[ovs-dev] Open vSwitch Design

Stephen Hemminger shemminger at vyatta.com
Fri Nov 25 05:20:21 UTC 2011


On Thu, 24 Nov 2011 17:30:33 -0500
jamal <hadi at cyberus.ca> wrote:

> Jesse,
> 
> I am going to try and respond to your comments below.
> 
> On Thu, 2011-11-24 at 12:10 -0800, Jesse Gross wrote:
> 
> > 
> >  * Switching infrastructure:  As the name implies, Open vSwitch is
> > intended to be a network switch, focused on
> > virtualization/OpenFlow/software defined networking.  This means that
> > what we are modeling is not actually a collection of flows but a
> > switch which contains a group of related ports, a software virtual
> > device, etc.  The switch model is used in a variety of places, such as
> > to measure traffic that actually flows through it in order to
> > implement monitoring and sampling protocols.
> 
> Can you explain why you couldnt use the current bridge code (likely with
> some mods)? I can see you want to isolate the VMs via the virtual ports;
> maybe even vlans on the virtual ports - the current bridge code should
> be able to handle that.

The way openvswitch works is that the flow table is populated
by user space. The kernel bridge works completely differently (it learns
about MAC addresses). 

> >  * Flow lookup:  Although used to implement OpenFlow, the kernel flow
> > table does not actually directly contain OpenFlow flows.  This is
> > because OpenFlow tables can contain wildcards, multiple pipeline
> > stages, etc. and we did not want to push that complexity into the
> > kernel fast path (nor tie it to a specific version of OpenFlow).
> > Instead an exact match flow table is populated on-demand from
> > userspace based on the more complex rules stored there.  Although it
> > might seem limiting, this design has allowed significant new
> > functionality to be added without modifications to the kernel or
> > performance impact.
> 
> This can be achieved easily with zero changes to the kernel code.
> You need to have default filters that redirect flows to user space
> when you fail to match.

Actually, this is what puts me off on the current implementation.
I would prefer that the kernel implementation was just a software
implementation of a hardware OpenFlow switch. That way it would
be transparent that the control plane in user space was talking to kernel
or hardware.

> >  * Packet execution:  Once a flow is matched it can be output,
> > enqueued to a particular qdisc, etc.  Some of these operations are
> > specific to Open vSwitch, such as sampling, whereas others we leverage
> > existing infrastructure (including tc for QoS) by simply marking the
> > packet for further processing.
> 
> The tc classifier-action-qdisc infrastructure handles this.
> The sampler needs a new action defined.

There are too many damn layers in the software path already.

> >  * Userspace interfaces:  One of the difficulties of having a
> > specialized, exact match flow lookup engine is maintaining
> > compatibility across differing kernel/userspace versions.  This
> > compatibility shows up heavily in the userspace interfaces and is
> > achieved by passing the kernel's version of the flow along with packet
> > information.  This allows userspace to install appropriate flows even
> > if its interpretation of a packet differs from the kernel's without
> > version checks or maintaining multiple implementations of the flow
> > extraction code in the kernel.
> 
> I didnt quiet follow - are we talking about backward/forward
> compatibility?

The problem is that there are two flow classifiers, one in OpenVswitch
in the kernel, and the other in the user space flow manager. I think the
issue is that the two have different code.

Is the kernel/userspace API for OpenVswitch nailed down and documented
well enough that alternative control plane software could be built?


> > It's obviously possible to put this code anywhere, whether it is an
> > independent module, in the bridge, or tc.  Regardless, however, it's
> > largely new code that is geared towards this particular model so it
> > seems better not to add to the complexity of existing components if at
> > all possible.
> 
> I am still not seeing how this could not be done without the
> infrastructure that exists. Granted, the user space brains - thats where
> everything else resides - but you are not pushing that i think.





More information about the dev mailing list