[ovs-dev] [rfc 0/6] merge of datapath into upstream kernel tree
horms at verge.net.au
Mon Aug 30 07:36:09 UTC 2010
On Thu, Aug 26, 2010 at 07:41:50PM -0700, Jesse Gross wrote:
> On Thu, Aug 26, 2010 at 5:08 AM, Simon Horman <horms at verge.net.au> wrote:
> > On Wed, Aug 25, 2010 at 09:33:01PM -0700, Jesse Gross wrote:
> >> On Wed, Aug 25, 2010 at 12:08 AM, Simon Horman <horms at verge.net.au> wrote:
> >> > * The patch description needs work
> >> Have to think about this one. There's some general information in the
> >> README file but I don't want it to sound too much like marketing.
> >> Also, I think the description in Kconfig could use a little bit of
> >> work as well. In particular it refers to the userspace process as the
> >> "controller", when in fact userspace can be directed from across the
> >> network by a "controller". Since there already has been some
> >> confusion about the roles of the different components, we should
> >> definitely clear this up.
> > I'm certainly open to reworking the Kconfig description.
> Maybe something like:
> Open vSwitch is a multilayer Ethernet switch targeted at virtualized
> environments. In addition to supporting a variety of features
> expected in a traditional hardware switch, it enables fine-grained
> programmatic extension and control through the OpenFlow protocol.
> This control is useful in a wide variety of applications but is
> particularly important in multi-server virtualization deployments,
> which are often characterized by highly dynamic endpoints and the need
> to maintain logical abstractions for multiple tenants.
> The Open vSwitch datapath provides an in-kernel fast path for packet
> forwarding. It is complemented by a userspace daemon, ovs-vswitchd,
> which is able to accept configuration from a variety of sources and
> translate it into packet processing rules.
> See openvswitch.org for more information.
> If unsure, say N.
> We may be able to use some or all of this as a patch description as well.
Thanks. I've put that text in both Kconfig and the patch description.
> > I agree that we need to think about how the out-of-tree
> > code and the in-tree code will be kept in sync. As it stands
> > I don't have any particularly good ideas there - other than
> > that patches will need to be back/forward/cross-ported if
> > the out-of-tree code needs to remain for compatibility reasons.
> Unfortunately we're going to need to maintain the out of tree code for
> a while. It's going to take a long time for the merged code to
> trickle down into shipping products (like hypervisors) that we'll want
> to be able to work with.
> >> > * I'm not sure where we want the code merged,
> >> > this patch places the code in drivers/staging/ovs-datapath
> >> I thought that we had discussed skipping drivers/staging/ and going
> >> straight in? What about net/openvswitch?
> > Sure. In that case I think it would be best to start a discussion
> > on netdev to see what people think. Either that or post the next
> > round of rfc patches there.
> Yes, we should probably start paving the way on netdev.
I have initiated a discussion there.
> > [ BTW, is posting this dev@ list moderated for non-members?
> > If so a) posting to to netdev and dev won't fly and
> > b) I probably should change the debian maintainer field
> > (completely unrelated to these patches) ]
> It is currently setup to require moderator approval for non-members.
> I've asked that this be removed to facilitate broader discussions.
Could you (or anyone else) let me know when that is done?
More information about the dev