On Wed, Nov 25, 2015 at 9:34 AM, Pravin Shelar <[email protected]> wrote: > On Wed, Nov 25, 2015 at 10:39 PM, Jesse Gross <[email protected]> wrote: >> On Wed, Nov 25, 2015 at 6:17 AM, Pravin Shelar <[email protected]> wrote: >>> On Wed, Nov 25, 2015 at 6:55 AM, Jesse Gross <[email protected]> wrote: >>>> On Tue, Nov 24, 2015 at 2:40 PM, Joe Stringer <[email protected]> wrote: >>>>> On 23 November 2015 at 21:30, Pravin B Shelar <[email protected]> wrote: >>>>>> Following patch adds support for lwtunnel to OVS datapath. >>>>>> With this change OVS datapath detect lwtunnel support and >>>>>> make use of new APIs if available. On older kernel where the >>>>>> support is not there the backported tunnel modules are used. >>>>>> These backported tunnel devices acts as lwtunnel devices. >>>>>> I tried to keep backported module same as upstream for easier >>>>>> bug-fix backport. Since STT and LISP are not upstream OVS >>>>>> always needs to use respective modules from tunnel compat layer. >>>>>> To make it work on kernel 4.3 I have converted STT and LISP >>>>>> modules to lwtunnel API model. >>>>>> >>>>>> lwtunnel make use of skb-dst to pass tunnel information to the >>>>>> tunnel module. On older kernel this is not possible. So the in >>>>>> case of old kernel metadata ref is stored in OVS_CB and direct >>>>>> call to tunnel transmit function is made by respective tunnel >>>>>> vport modules. Similarly on receive side tunnel recv directly >>>>>> call netdev-vport-receive to pass the skb to OVS. >>>>>> >>>>>> Major backported components include: >>>>>> Geneve, GRE, VXLAN, ip_tunnel, udp-tunnels GRO. >>>>>> >>>>>> Signed-off-by: Pravin B Shelar <[email protected]> >>>>> >>>>> Jesse, I've provided some minor feedback below but overall it looks OK >>>>> to me. Did you have any thoughts on this? >>>> >>>> I'm basically happy with this. It seems more or less impossible to >>>> review this in detail on every kernel but I looked at the overall >>>> structure and some key areas and it seems generally reasonable. Given >>>> that Joe did some compile testing on different kernels, I think that's >>>> good enough and we can work out any problems as we encounter them. >>>> >>>> One specific thing that I noticed is that I believe that there is a >>>> regression in regards to compatibility with GRE devices outside of >>>> OVS. We used to not register the compat GRE protocol handler until we >>>> actually created a GRE tunnel but now we do it immediately on OVS >>>> kernel load, which will block the upstream module from loading. >>>> >>> Which upstream module are you referring to? In the patch gre cisco >>> protocol is registered which only blocks ovs vport-gre module. I do >>> not think we can insmod upstream OVS and out of tree OVS modules at >>> same time anyways. >> >> I mean the upstream ip_gre module. If it is loaded, it will cause OVS >> module init to fail and conversely if OVS is already loaded (even >> without any GRE tunnels) it will cause the ip_gre module to fail to >> load. >> > ip_gre module should work fine with introduction of > gre_cisco_register() API. This allows multiple modules to register for > ip-gre protocol packets. On kernel that do not have the API we have > this issue. I am not sure if we need to worry about those kernels.
OK, I see now. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
