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. 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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev