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