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

Jesse Gross jesse at nicira.com
Fri Oct 4 22:19:32 UTC 2013


On Fri, Oct 4, 2013 at 6:30 AM, Kyle Mestery (kmestery)
<kmestery at cisco.com> wrote:
> 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.

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.



More information about the dev mailing list