On Fri, Oct 4, 2013 at 6:30 AM, Kyle Mestery (kmestery) <kmest...@cisco.com> wrote: > On Oct 3, 2013, at 2:31 PM, Jesse Gross <je...@nicira.com> wrote: >> On Thu, Oct 3, 2013 at 9:46 AM, Kyle Mestery (kmestery) >> <kmest...@cisco.com> wrote: >>> So, we realize the need to add the NSH code upstream into the kernel. >>> But in parallel to this work, we're wondering if it would be ok to add a new >>> vport-nsh in the data path code. This would allow for stacking NSH headers >>> on whatever tunnel is required, per the RFC, by using flows to direct >>> traffic >>> between ports. In parallel, we're going to work to get the NSH code upstream >>> into the Linux kernel and the iproute2 package for configuration using a >>> CLI. >>> >>> Does this approach sound ok? >> >> Since we've been pushing hard to make the out-of-tree code closely >> track upstream, I would be very hesitant to apply anything that isn't >> ready to go upstream. >> > Makes sense. Is the eventual goal to remove the need for the out of tree > kernel module completely? > >> Ready for upstream doesn't necessarily mean that configuration has to >> available through iproute2 but it should be in an essentially final >> form and make sense purely in the context of what's there plus the new >> OVS code. >> > Got it. We'll make sure to finalize all the interfaces as well. I guess the > goal for now would be to push the NSH encap/decap upstream into the > kernel, but rely on the out of tree kernel for previous kernel support. > >> I'm not sure if that's true of what you're proposing or would this be >> more temporary? > > Well, I see the out of tree kernel module as a way to support older > kernels with features which are upstream in newer kernels, correct > me if I'm wrong here. But overall, I think we're both on the same page > here.
I agree that the out-of-tree code will be important for backports for the foreseeable future but otherwise the goal is definitely to have 1:1 parity with the current version of upstream Linux. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
