On Thu, Sep 24, 2015 at 9:01 PM, Pravin Shelar <pshe...@nicira.com> wrote: > On Thu, Sep 24, 2015 at 8:37 PM, Jesse Gross <je...@nicira.com> wrote: >> On Thu, Sep 24, 2015 at 8:06 PM, Pravin Shelar <pshe...@nicira.com> wrote: >>> On Thu, Sep 24, 2015 at 7:11 PM, Jesse Gross <je...@nicira.com> wrote: >>>> On Thu, Sep 24, 2015 at 3:18 PM, Pravin Shelar <pshe...@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev