On Thu, May 29, 2014 at 4:38 PM, Tom Herbert [off-list ref] wrote:

On Thu, May 29, 2014 at 3:45 PM, Jesse Gross [off-list ref] wrote:

quoted

On Wed, May 28, 2014 at 9:24 PM, Tom Herbert [off-list ref] wrote:

quoted

diff --git a/net/openvswitch/vport-vxlan.c b/net/openvswitch/vport-vxlan.c
index a93efa3..0edbd95 100644
--- a/net/openvswitch/vport-vxlan.c
+++ b/net/openvswitch/vport-vxlan.c

@@ -122,7 +122,7 @@ static struct vport *vxlan_tnl_create(const struct vport_parms *parms)
        vxlan_port = vxlan_vport(vport);
        strncpy(vxlan_port->name, parms->name, IFNAMSIZ);

-       vs = vxlan_sock_add(net, htons(dst_port), vxlan_rcv, vport, true, false);
+       vs = vxlan_sock_add(net, htons(dst_port), vxlan_rcv, vport, true, 0);

OVS actually already has support for specifying that checksums should
be calculated/verified plumbed down to the kernel. This is used
already with GRE (via the TUNNEL_CSUM flag). If we modeled VXLAN
similarly then it might make the two protocols more similar and give
us OVS support for free.

I tend to agree, it would be nice if vxlan would be configured like
GRE, use tnl_ptk_info, etc. But, it looks like vxlan is pretty
divergent, so I'd like to decouple doing that from this patch set.

For setting use of csums in vxlan-ovs it should be a matter of adding
IFLA_VXLAN_UDP_CSUM (IFLA_VXLAN_UDP_ZERO_CSUM6_TX for IPv6) flags
argument to vxlan_sock_add. Do you see any issues with that?

The problem is that OVS actually does this on a per-flow basis, on
transmit specifying whether the checksum should be computed and
recording the presence of the checksum on receive. All of the policy,
such as whether checksums are required, is handled in userspace in a
tunnel-independent manner. I don't think that we need to restructure
VXLAN in this patch (although I agree it would be nice) but OVS needs
a little bit more granularity than configuring the socket.