[ovs-dev] [rfc 0/6] merge of datapath into upstream kernel tree
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
> * 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
> > * 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