[ovs-dev] [PATCH 1/8] nsh: datapath support for network service headers

[Kyle Mestery (kmestery)]

On Oct 3, 2013, at 2:31 PM, Jesse Gross <jesse at nicira.com> wrote:
> On Thu, Oct 3, 2013 at 9:46 AM, Kyle Mestery (kmestery)
> <kmestery at 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