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:nit...@vmware.com] Sent: Sunday, 15 March, 2015 18:23 To: Sorin Vinturis Cc: dev@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 <nit...@vmware.com> -- Nithin _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
