[ovs-dev] [PATCH 3/3] datapath: Add support for 4.3 kernel.

[Pravin Shelar]

On Thu, Sep 24, 2015 at 8:37 PM, Jesse Gross <jesse at nicira.com> wrote:
> On Thu, Sep 24, 2015 at 8:06 PM, Pravin Shelar <pshelar at nicira.com> wrote:
>> On Thu, Sep 24, 2015 at 7:11 PM, Jesse Gross <jesse at nicira.com> wrote:
>>> On Thu, Sep 24, 2015 at 3:18 PM, Pravin Shelar <pshelar at nicira.com> wrote:
>>>> I am not targeting STT and LISP in this 4.3 patch set, Once this
>>>> backport are done, I will work on these tunnel implementation.
>>>
>>> Even if it isn't done immediately, do you have an idea of what it
>>> would look like long term? Not just for STT and LISP but also any
>>> future feature backports to the tunnels that are upstream (like IPv6)?
>>> It seems like this could be a real pain to maintain for both pre-4.3
>>> and post-4.3 kernels.
>>
>> I do not think we have option for STT and LISP but to maintain two
>> different code bases.
>> For IPv6 tunnels, I think it would be available on kernel which
>> support it. So only kernel from distributions which has backported
>> IPv6 tunnels and kernel 4.4 or newer will support such tunnels.
>
> I think this would be the first feature that isn't available with the
> out of tree module running on older kernels. I believe any other
> limitations that we might have are strictly performance related, at
> worst. If that's correct, that would make this a significant departure
> and something that we shouldn't do lightly.
>
ok, Lets revisit it once IPv6 support is merged upstream.

> I wonder if it might be possible to create a shim layer (perhaps using
> per-CPU data as a safe place to store things) to emulate the skb dst
> changes to carry metadata around purely internal to OVS. We could then
> have backports of the netdevices (or new netdevices in the case of STT
> and LISP) in the OVS tree, which should be possible on all kernels.
> That would seem to eliminate both problems if we can pull it off.

This is good idea!
I need to check if skb processing can be migrated to different CPU by
flow steering in our case.