datapath-windows: Support for custom VXLAN tunnel port
authorSorin Vinturis <svinturis@cloudbasesolutions.com>
Wed, 27 May 2015 16:58:25 +0000 (16:58 +0000)
committerBen Pfaff <blp@nicira.com>
Wed, 27 May 2015 19:36:27 +0000 (12:36 -0700)
commit5e82ceefd12dfcb954da48d027b47d98dc53676a
treea13059a1a95de2ffb35b8bd94783cee4338ad484
parentb6ec827fe0edb5478ac0f580eaa0597b1166a0fb
datapath-windows: Support for custom VXLAN tunnel port

The kernel datapath supports only port 4789 for VXLAN tunnel creation.
Added support in order to allow for the VXLAN tunnel port to be
configurable to any port number set by the userspace.

The patch also checks to see if an existing WFP filter, for the
necessary UDP tunnel port, is already created before adding a new one.
This is a double check, because currently the userspace also verifies
this, but it is necessary to avoid future issues.

Custom VXLAN tunnel port requires the addition of a new WFP filter
with the new UDP tunnel port. The creation of a new WFP filter is
triggered in OvsInitVxlanTunnel function and the removal of the WFP
filter in OvsCleanupVxlanTunnel function.
But the latter functions are running at IRQL = DISPATCH_LEVEL, due
to the NDIS RW lock acquisition, and all WFP calls must be running at
IRQL = PASSIVE_LEVEL. This is why I have created a system thread which
records all filter addition/removal requests into a list for later
processing by the system thread. The ThreadStart routine processes all
received requests at IRQL = PASSIVE_LEVEL, which is the required IRQL
for the necessary WFP calls for adding/removal of the WFP filters.

The WFP filter for the default VXLAN port 4789 is not added anymore at
filter attach. All WFP filters for the tunnel ports are added when the
tunnel ports are initialized and are removed at cleanup. WFP operation
status is then reported to userspace.

It is necessary that OvsTunnelFilterUninitialize function is called
after OvsClearAllSwitchVports in order to allow for the added WFP
filters to be removed. OvsTunnelFilterUninitialize function closes the
global engine handle used by most of the WFP calls, including filter
removal.

Signed-off-by: Sorin Vinturis <svinturis@cloudbasesolutions.com>
Reported-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Reported-at: https://github.com/openvswitch/ovs-issues/issues/66
Acked-by: Nithin Raju <nithin@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
datapath-windows/ovsext/Datapath.c
datapath-windows/ovsext/Netlink/Netlink.c
datapath-windows/ovsext/Netlink/NetlinkError.h
datapath-windows/ovsext/Switch.c
datapath-windows/ovsext/Tunnel.h
datapath-windows/ovsext/TunnelFilter.c
datapath-windows/ovsext/TunnelIntf.h
datapath-windows/ovsext/Vport.c
datapath-windows/ovsext/Vport.h
datapath-windows/ovsext/Vxlan.c
datapath-windows/ovsext/Vxlan.h