Re: [PATCH net v2 2/3] geneve: Relax MTU constraints

On Thu, Feb 18, 2016 at 8:54 AM, David Wragg [off-list ref] wrote:

Tom Herbert [off-list ref] writes:

quoted

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