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

Jesse Gross jesse at nicira.com
Fri Aug 27 02:41:50 UTC 2010


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.

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

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




More information about the dev mailing list