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