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

Jesse Gross jesse at nicira.com
Thu Sep 24 20:18:18 UTC 2015


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.

Either way, I think my comment about trying to use the existing
supporting functions such as GSO and socket registration is still
valid and would make the code easier to understand.



More information about the dev mailing list