[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111123053418.GJ3344@sequoia.sous-sol.org>
Date: Tue, 22 Nov 2011 21:34:18 -0800
From: Chris Wright <chrisw@...s-sol.org>
To: Stephen Hemminger <shemminger@...tta.com>
Cc: David Miller <davem@...emloft.net>, jesse@...ira.com,
netdev@...r.kernel.org, dev@...nvswitch.org
Subject: Re: [GIT PULL v2] Open vSwitch
* Stephen Hemminger (shemminger@...tta.com) wrote:
> Maybe someone with more insight than me can explain the relationship
> between Openflow and Open vSwitch. It maybe that the portability
> of Openflow makes the old qdisc, classifiers to use/implement.
I'm sure I can't answer the last bit as well as you'd like. But openflow
is the control plane protocol between a controller and a switch.
The controller's job is to program the switch to enforce the controller's
view of network policy. For ovs, the protocol termination is essentially
in userspace.
The switch's flow table is managed via the controller and obviously
consulted on the datapath in the kernel. I think Jesse was already clear
that portability concerns were constrained to userspace. You could
imagine all kinds of funky ways that userspace could in turn ask the
kernel to enforce the flow table actions that the controller requested.
Your and Jamal's questions seem pretty clear...what does ovs do that
tc can't/doesn't and is that a fundamental gap, a cumbersome interface,
or a need to port existing functionality.
The only part I was unclear on in that question is whether you're
talking about the internals only, or also the netlink interface?
thanks,
-chris
--
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