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

Reply via email to