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

Simon Horman horms at verge.net.au
Thu Aug 26 12:08:16 UTC 2010

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.

> > * Please suggest items for the TODO

Thanks, I will update the TODO accordingly.

> A few of the items that we have for TODO are pretty straightforward
> fixes that apply equally well to the current Open vSwitch tree as they
> do to the merge.  To me it makes sense to just take care of these now
> rather than make other people look at them (and probably repeatedly
> comment on them).  The ones on the list currently that fall into this
> category:
> * Using pr_*
> * Removing trailing whitespace (probably some other formatting fixes as well)
> * Stephen's comments about make_writable().
> Bigger changes properly belong in the TODO so we can think some and
> get  feedback.  Examples of these changes:
> * Ripping out compatibility code (I don't think that this is
> controversial or requires much discussion but it will create a large
> diff against the main Open vSwitch tree which will make patch handling
> more difficult while we sort out the other things.)

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.

> * The userspace interface.  I expect this one to generate a fair
> amount of discussion.  Ben has been doing some thinking about this to
> get the ball rolling.
> * Network namespace support.  Need to decide exactly what problem we
> are trying to solve (i.e. switching within a namespace or between
> namespaces).
> >
> > * 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.

[ 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) ]

> > * brcompat has been omitted
> >
> > * compat.h and linux-2.6/* have been omitted
> Good riddance.


> > * The subsequent patches in this series should probably
> >  be folded into this one before submitting the
> >  code for merging. I broke them out to allow the
> >  changes to be more easily inspected.
> Good idea, breaking it out makes it a lot easier to review.
> >
> > * Compile tested only
> >
> > * Compiles cleanly against
> >  - Linus's current tree (2.6.36-rc2+α)
> >  - 2.6.36-rc2
> >  - 2.6.36-rc1
> If we are skipping drivers/staging/ we should be targeting
> net-next-2.6.  The current tree compiles against it (modulo
> IFF_OVS_DATAPATH, which is now defined twice if you have the compat
> code there).

Yes, I agree. If we are targeting net/openvswitch then the patches
should be against net-next-2.6. And updating the patches to against
that tree should be trivial.

More information about the dev mailing list