datapath: compat: Fix compilation 3.11

Kernel 3.11 is only kernel where GRE APIs are available but
not vxlan. Add check for vxlan xmit to detect this case.

Reported-by: Dave Benson <dbenson@verdantnetworks.com>
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
netlink-socket: Always pass the output buffer in a transaction.

We need to pass down the output buffer so that the kernel can return
transaction status - error or otherwise.

Also, we were processing the output buffer only when when
'txn->reply != NULL' ie when the caller specified an ofpbuf for the
reply. In this patch, the code has been updated to process the reply
unconditionally, but making sure to copy the reply to the 'txn->reply'
only when it is not NULL. The reason for the unconditional processing is
we can pass up transactional errors in 'txn->error'. Otherwise, it
results in an endless loop of calling nl_transact().

Signed-off-by: Nithin Raju <nithin@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ankur Sharma <ankursharma@vmware.com>
datapath-windows: Add netlink command: vport new

Does the following:
a. before creating the vport, makes sure there is no existing vport
with the same ovs (datapath) port name. If this is not so, it means
that the specified port already exists: it returns NL_ERROR_EXIST.
b. looks up the vport:
  o) if the vport type is "internal", then the internal vport of the
  hyper-v switch is yielded.
  o) if the vport type is "netdev" and the vport ovs (datapath) name
  is "external", then the external vport is yielded. The switch can
  have only one "external" vport. The method of looking up the
  "external" port can be changed later, if a better method is found.
  o) if the vport type is "netdev" but the name is not "external",
  then a VM VNic is assumed, so the vport is looked up by hyper-v
  switch port friendly name.
  o) if none of the above, a tunneling vport type is expected, which
  in our case, at the moment, can only be the one vxlan vport. Only
  one vxlan vport is allowed, and it's saved in
  switchContext->vxlanVport. The tunneling vport is the only kind
  which is created in the netlink command vport new, because it does
  not have a hyper-v switch port counterpart.
c. if the vport could not be found (non-tunneling vports), then the
NL_ERROR_INVAL is returned to the userspace.
d. if the vport was found, but it has a valid ovs (datapath) port
number, it means that this port was already created by a netlink
command vport new. Therefore, NL_ERROR_EXIST is returned to the
userspace.
e. if the netlink command vport new specified an ovs (datapath) port
number, then it means that the userspace is trying to re-create a
vport: that specified port number will be used. Otherwise, a new
ovs (datapath) port number is computed and assigned to the vport.
f. the ovsName field of the vport is set to the name given by the
OVS_VPORT_ATTR_NAME netlink attribute. The ovsNameLen is no longer
stored in the OVS_VPORT_ENTRY struct, because ovsName is
null-terminated.
g. the "portOptions" are set to the vport, if the attribute
OVS_VPORT_ATTR_OPTIONS was given. Otherwise, it is set to NULL.
portOptions is a PNL_ATTR, which is yet to be implemented. The
only option available for now would be vxlan udp destination port,
but we have a constant value there, so this option is not yet needed.
h. the upcall pid is set to the vport.
i. if the vport type is vxlan, then the vport pointer is also saved
to switchContext->vxlanVport.
j. Now that the ovs (datapath) port number and the ovs name were set,
the vport can be added to the hash array of vports, hashed on ovs name
and to the hash array of vports hashed by ovs (datapath) port number.
k. the reply is yielded to the userspace.

Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com>
Acked-by: Nithin Raju <nithin@vmware.com>
Acked-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Eitan Eliahu <eliahue@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
datapath-windows: Add netlink command vport delete

Deletion of a vport is now handled both by the netlink command vport
delete and the hyper-v switch port delete handler. If a netlink
command vport delete is requested on a vport that has no hyper-v
switch port counterpart (i.e., it is a tunnel port, or or the hyper-v
switch virtual nic is disconnected), the vport is deleted and removed.

If the hyper-v switch port delete is requested (i.e. the VNic is
disconnecting) and the ovs (datapath) part is deleted (i.e. was
deleted by netlink command vport delete, or was never created by
an netlink command vport new), then the hyper-v switch port delete
function handler deletes and removes the vport.

If the hyper-v switch port delete is requested while its datapath
counterpart is still alive, or, when the netlink command vport delete
is requested while the hyper-v switch port is still alive, the port
is only marked that it's part is deleted - the field hvDeleted was
added to OVS_VPORT_ENTRY to specify if the hyper-v switch port side
was deleted; if the ovs (datapath) port number is invalid, then it
means that the ovs (datapath) side of the port is deleted (or, not
created).

Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com>
Acked-by: Nithin Raju <nithin@vmware.com>
Acked-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Eitan Eliahu <eliahue@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
datapath-windows: remove vport from lists upon deletion

In this patch, we fix a bug in the vport delete code. When a vport is
deleted using a netlink command, we need to remove it from the
'ovsNamHashArray' and the 'portNoHashArray' as well. Addition of a vport
adds the port to the lists.

Signed-off-by: Nithin Raju <nithin@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
datapath-windows: pass NDIS_RWL_AT_DISPATCH_LEVEL instead of BOOLEAN

In 'OvsAcquireDatapathRead()' and 'OvsAcquireDatapathWrite()', we seem
to be passing a BOLEAN instead of NDIS_RWL_AT_DISPATCH_LEVEL.

Signed-off-by: Nithin Raju <nithin@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
datapath-windows: delete ports from portIdHashArray during cleanup

Signed-off-by: Nithin Raju <nithin@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
datapath-windows: loop iterator fixes in Vport.c

Validation:
- With these fixes, we no longer see the freeze during module
uninstallation or when we try to add a new port.
- We are able to add a port called "internal of type internal using:
ovs-dpctl.exe add-if ovs-system internal,type=internal

Signed-off-by: Nithin Raju <nithin@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
datapath-windows: Transactional error support in Flow commands.

In this patch we added the code to handle transactional errors
in flow commands.

Signed-off-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Nithin Raju <nithin@vmware.com
Signed-off-by: Ben Pfaff <blp@nicira.com>
datapath-windows: Validate ETHERTYPE and ETHERNET attribute.

During vswitchd boot up kernel is receiving FLOW_ADD commands
without ETHERTYPE attribute. Added additional check for the same
in this patch. During the same phase kernel is also receiving
packet_execute with no ETHERNET attribute.

Signed-off-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Nithin Raju <nithin@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
datapath-windows: Reply for Flow Flush.

Added changes to send a reply for FLOW_FUSH case. This is needed
as with nithin's transaction reply changes we'll need reply for each
command.

This patch also contains minor fixes for sending replies in
success case as well.

Signed-off-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Nithin Raju <nithin@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
datapath-windows: Remove setting of replyLen to zero.

This was one of the review comment which i forgot to address in
FLOW_DUMP checkin. We do not need to explicitly set replyLen to zero
 as caller would have already set it.

Signed-off-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Nithin Raju <nithin@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
datapath-windows: Remove invalid assertion.

Assert(rc) would always hit for a valid case, hence
replaced it with error code based check.

Signed-off-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Nithin Raju <nithin@vmware.com>
Tested-by: Nithin Raju <nithin@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
datapath-windows: Fix assertion in Netlink.c

NlBufAt should be called with valid boundary limits (within head and tail).
Incorrect argument to NlBufAt was leading to assert hit, fixed the same.

Signed-off-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Nithin Raju <nithin@vmware.com>
Tested-by: Nithin Raju <nithin@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
ovs-vtep: Add support for bfd tunnels.

The VTEP emulator creates one OVS bridge for every logical switch and then
programs flow in it based on learned local macs and controller programmed
remote macs.

Multiple logical switches can have multiple OVS tunnels to the
same remote machine (with different tunnel ids). But VTEP schema expects
a single BFD session between two physical locators. Therefore
create a separate bridge ('bfd_bridge') and create a single OVS tunnel
between two physical locators (using reference counter).

The creation of BFD tunnels by the VTEP emulator is mostly for reporting
purposes. That is, it can be used by the controller to figure out that
a remote port is down. The emulator itself does not base any of its
forwarding decisions based on the state of a bfd tunnel.

Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ariel Tubaltsev <atubaltsev@vmware.com>
nicira-ext.h: Update comments

Signed-off-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Acked-by: Ben Pfaff <blp@nicira.com>