[ovs-dev] [rfc 0/6] merge of datapath into upstream kernel tree

Simon Horman 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.

Understood.

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

http://marc.info/?l=linux-netdev&m=128314968627015&w=2

> > [ 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 mailing list