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: >> On Thu, Sep 24, 2015 at 1:18 PM, Jesse Gross <je...@nicira.com> wrote: >>> On Wed, Sep 23, 2015 at 8:13 PM, Pravin Shelar <pshe...@nicira.com> wrote: >>>> On Wed, Sep 23, 2015 at 5:57 PM, Jesse Gross <je...@nicira.com> wrote: >>>>> I understand that why we need to re-enable the various protocol >>>>> modules now but is it possible to avoid all of the supporting code? It >>>>> seems like we should be able to continue using the upstream >>>>> implementations of GSO, socket registration, etc. >>>> >>>> I was thinking using compat version on 4.3 for this case. since this >>>> code will be only used when using vswitchd which creates tunnel vport >>>> using ovs-vports rather than tunnel netdev. I am planing on changing >>>> vswitchd so that it creates netdevs for tunnel vport. So soon this >>>> code will be compat code. So to keep things simple I decided to go >>>> this way. But if you want I can change the patch to use kernel tunnel >>>> netdevice for ovs-tunnel-vport implementation. >>> >>> I agree it makes sense to not spend a lot time worrying about >>> optimizing the backport on 4.3 if we won't use it. (In particular, if >>> we don't use netdevices we will lose GRO.) One thing that I do worry >>> about by not using netdevices at all in 4.3 is that it will cause the >>> non-compat code to diverge from upstream. (I know this is still really >>> compat code but it is different in the sense that it is upstream.) >>> >>> Another related question is how we will maintain the protocol modules >>> over time? Will we convert STT and LISP to modules? And what about >>> backports to the modules that are upstream? (IPv6 support is something >>> that comes to mind as a feature in the relatively near future.) If so, >>> the performance will become important again. >>> >> 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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev