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

Jesse Gross jesse at nicira.com
Fri Sep 25 02:11:30 UTC 2015


On Thu, Sep 24, 2015 at 3:18 PM, Pravin Shelar <pshelar at nicira.com> wrote:
> On Thu, Sep 24, 2015 at 1:18 PM, Jesse Gross <jesse at nicira.com> wrote:
>> On Wed, Sep 23, 2015 at 8:13 PM, Pravin Shelar <pshelar at nicira.com> wrote:
>>> On Wed, Sep 23, 2015 at 5:57 PM, Jesse Gross <jesse at 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.



More information about the dev mailing list