On Fri, Sep 28, 2012 at 3:44 PM, Kyle Mestery (kmestery) <kmest...@cisco.com> wrote: > On Sep 28, 2012, at 5:40 PM, Jesse Gross wrote: >> On Fri, Sep 28, 2012 at 11:59 AM, Kyle Mestery (kmestery) >> <kmest...@cisco.com> wrote: >>> On Sep 28, 2012, at 1:12 PM, Jesse Gross wrote: >>>> Now that both the kernel and userspace can handle information about >>>> the tunnel outer headers this adds userspace support for communicating >>>> between the two. At the moment userspace doesn't know how to do >>>> anything with the extra information on receive and will only generate >>>> actions containing tun_id. However, both sides know how to ignore the >>>> extra information. >>>> >>>> Signed-off-by: Jesse Gross <je...@nicira.com> >>> >>> >>> The patch I just submitted overlaps with this patch a little bit. I think >>> there wasn't >>> a really set delineation between what I was doing and what you were doing, >>> so >>> we may have to merge this patch with mine. I think we both pretty much made >>> similar changes though, so it shouldn't be too bad. Acking this patch for >>> now, >>> assuming we'll work through the merge bits. >> >> I agree the changes are pretty similar. My inclination is that it's a >> little easier to use the version in my patch if that's OK with you for >> a couple of reasons: >> * I'm not sure that the change logically belongs in the second patch >> of your series. It could be moved into the first patch though. >> * There isn't much benefit to userspace supporting both models of >> kernel tunnel implementation because the kernel will reject any >> actions that it doesn't understand. As a result, once this patch goes >> in we will immediately require a new version of the kernel module. >> Ideally I'd like to push that requirement back as late as practical so >> that we can start applying patches without worrying about breaking >> compatibility more than necessary. However, when we do put it in, we >> might as well go all the way and drop support for the old mechanism in >> userspace. > > That makes sense to me. Do you want me to rebase my first patch and fold this > one into that? I can then rework my second patch based on this. Or even, we > could move this patch as a second patch in my series, and I could just rebase > my third patch.
I actually don't think that much needs to be done - this patch depends on the previous patch to do all the userspace flow changes and we don't really want to roll all of them together. I would just drop the odp-util.c changes from your second patch and then your patches fit in right before my series. That will avoid the conflict and shouldn't have any dependency problems. I haven't had a chance to review your patches that closely yet but my impression is that the bulk of the second patch doesn't have any changes visible to userspace. Is that right? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
