On Thu, Feb 18, 2016 at 8:54 AM, David Wragg <david@weave.works> wrote: > Tom Herbert <t...@herbertland.com> writes: >> Please implement like in ip_tunnel_change_mtu (or better yet call it), >> that is the precedent for tunnels. > > I've made geneve_change_mtu follow ip_tunnel_change_mtu in v2. > > If it were to call it instead, are you suggesting just passing in > t_hlen? Or restructuring geneve.c to re-use the whole ip_tunnel > infrastructure? > I'll leave that to you to decide if that is feasible or makes sense, but ip_tunnel does do some other interesting things. Support for geneve could easily be implemented using ip_tunnel_encap facility. The default MTU on the device is set based on the MTU of the outgoing interface and tunnel overhead-- this should mitigate the possibility of a lot of fragmentation happening within the tunnel. Also, the output infrastructure caches the route for the tunnel which is a nice performance win.
> Also, I'm not sure where the 0xFFF8 comes from in > __ip_tunnel_change_mtu. Any ideas why 0xFFF8 rather than 0xffff? It > goes all the way back to the inital import of the kernel into git. > Yes, that's pretty ugly. Feel free to replace that with a #define or at least put a comment about it for the benefit of future generations. Thanks, Tom > David _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
