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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
