[ovs-dev] [PATCH v2 2/3] datapath-windows: Support for multiple VXLAN tunnels

Sorin Vinturis svinturis at cloudbasesolutions.com
Mon Mar 16 08:21:25 UTC 2015


Hi Nithin,

In the case the extension is unloaded while there are multiple VXLAN tunnels added, all of them will be released and the WFP filters removed. I have successfully tested this scenario.

The destination port from tunnel key is in reverse order, that is why I converted it.

Thanks,
Sorin

-----Original Message-----
From: Nithin Raju [mailto:nithin at vmware.com] 
Sent: Sunday, 15 March, 2015 18:23
To: Sorin Vinturis
Cc: dev at openvswitch.org
Subject: Re: [ovs-dev] [PATCH v2 2/3] datapath-windows: Support for multiple VXLAN tunnels

hi Sorin,
This change looks good.

Have you tested the scenario of unloading the OVS extension while the VXLAN ports exist in the kernel?

I had a minor comment as follows, but looks good otherwise.

> static __inline BOOLEAN
> OvsIsInternalVportType(OVS_VPORT_TYPE ovsType) { diff --git 
> a/datapath-windows/ovsext/Vxlan.c b/datapath-windows/ovsext/Vxlan.c 
> index cd3dc45..a22c425 100644
> --- a/datapath-windows/ovsext/Vxlan.c
> +++ b/datapath-windows/ovsext/Vxlan.c
> @@ -259,7 +259,7 @@ OvsDoEncapVxlan(PNET_BUFFER_LIST curNbl,
>         /* UDP header */
>         udpHdr = (UDPHdr *)((PCHAR)ipHdr + sizeof *ipHdr);
>         udpHdr->source = htons(tunKey->flow_hash | 32768);
> -        udpHdr->dest = VXLAN_UDP_PORT_NBO;
> +        udpHdr->dest = htons(tunKey->dst_port);

Tunnel key is generally in Network order already. Why do we need to convert it?

Acked-by: Nithin Raju <nithin at vmware.com>

-- Nithin



More information about the dev mailing list