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

Pravin Shelar pshelar at nicira.com
Fri Sep 25 07:47:14 UTC 2015


On Thu, Sep 24, 2015 at 9:01 PM, Pravin Shelar <pshelar at nicira.com> wrote:
> 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.

I gave it some more thought and I see following issues with using
per-cpu data to pass skb-dst.
1. Pre-emptive kernel.
2. Flow steering - RPS
3. skb async processing --- netdev backlog queue. There can be
multiple skb in queue  between tunnel device and OVS.

3rd issue is show stopper for per-cpu data structure. So now I am
exploring other data structure around this idea.



More information about the dev mailing list