Message-ID: <20111124212021.2ae2fb7f@s6510.linuxnetplumber.net>
Date:	Thu, 24 Nov 2011 21:20:21 -0800
From:	Stephen Hemminger <shemminger@...tta.com>
To:	jhs@...atatu.com
Cc:	hadi@...erus.ca, Jesse Gross <jesse@...ira.com>,
	netdev <netdev@...r.kernel.org>, dev@...nvswitch.org,
	David Miller <davem@...emloft.net>,
	Chris Wright <chrisw@...hat.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Eric Dumazet <eric.dumazet@...il.com>,
	John Fastabend <john.r.fastabend@...el.com>,
	Justin Pettit <jpettit@...ira.com>
Subject: Re: Open vSwitch Design

On Thu, 24 Nov 2011 17:30:33 -0500
jamal <hadi@...erus.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.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists