rhel7: Fix rpm install failure.

When trying to install the kernel module rpm built for RHEL7,
the install failed with following conflicts:

  # rpm -i kmod-openvswitch-2.3.1-1.el7.x86_64.rpm
    file /lib/modules/3.10.0-123.8.1.el7.x86_64/modules.devname
    from install of kmod-openvswitch-2.3.1-1.el7.x86_64 conflicts
    with file from package kernel-3.10.0-123.8.1.el7.x86_64

    file /lib/modules/3.10.0-123.8.1.el7.x86_64/modules.softdep
    from install of kmod-openvswitch-2.3.1-1.el7.x86_64 conflicts
    with file from package kernel-3.10.0-123.8.1.el7.x86_64

Similar issue has already been reported and solved here:

    https://bugzilla.redhat.com/show_bug.cgi?id=1003267

This commit applies the solution in the link to ovs.

Signed-off-by: Alex Wang <alexw@nicira.com>
Acked-by: Gurucharan Shetty <gshetty@nicira.com>
ovs-vswitchd: Fix high cpu utilization when acquire idl lock fails.

When ovs-vswitchd fails to acquire the ovsdb idl lock (either due to
contention or due to invalid database path), ovs-vswitchd will spin
on the global connectivity sequence number and consume 100% cpu.
This is in that the local copy is different to the global sequence
number and never updated when ovsdb idl is not locked.

To fix this issue, this commit makes ovs-vswitchd not checking the
global connectivity sequence number in that situation.

Reported-by: Ben Pfaff <blp@nicira.com>
Signed-off-by: Alex Wang <alexw@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
ovs-bugtool: Add fdb output for all bridges

Fdb entries can provide useful information. Collect them in bugtool.

Signed-off-by: Andy Zhou <azhou@nicira.com>
netdev-dpif: Add metadata to dpif-packet.

Today dpif-netdev has single metadat for given batch, since one
batch belongs to one port, but soon packets fro single tunnel ports
can belong to different ports, so we need to have per packet metadata.

Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
AUTHORS: Update my author entry.

Update the email address for myself in the AUTHORS file.

Signed-off-by: Kyle Mestery <mestery@mestery.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
datapath-windows: Remove the old IOCTL vport functions.

The old IOCTL vport functions (using the non-netlink device) are no
longer needed. They should be removed.

Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com>
Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Acked-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Eitan Eliahu <eliahue@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: Rename hyper-v switch port and nic handlers

Functions such as OvsCreatePort are vague in regard to who creates it or
when. It wasn't a problem thus far, since the vports were created,
updated and destroyed from one place only (hyper-v switch part). But
now, with the netlink implementation of the vport commands, a part of
the vport is constructed by the netlink vport add, and the other part
is constructed by the hyper-v switch nic and port handlers.

This patch renames the hyper-v switch nic and port handlers, so that
they are now prefixed by "Hv" instead of "Ovs", in order to clarify
which of the functions are nic or port handlers. This will make more
clear the usages from netlink vport commands side and from hyper-v
switch side. It will also make more obvious which nic and port
functions are helper functions.

Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com>
Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Acked-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Eitan Eliahu <eliahue@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: We don't need to keep validation ports in ovs

Validation ports are used internally by the hyper-v switch to validate
and verify settings for the real hyper-v switch ports that will be
connected to the VNic. The validation ports are of no use to us - we
must skip handling them, and return STATUS_SUCCESS as the OID result.

Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com>
Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Acked-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Eitan Eliahu <eliahue@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: Update OVS_SWITCH_CONTEXT: external and internal port

The fields externalVport and internalVport of the OVS_SWITCH_CONTEXT
struct are currently defined as PVOID. However, all over the code they
are used as POVS_VPORT_ENTRY. In order to improve clarity and reduce the
need for useless casts to POVS_VPORT_ENTRY, this patch changes the type
from PVOID to POVS_VPORT_ENTRY.

This patch does not cleanup the code that already uses casts to
POVS_VPORT_ENTRY. This cleanup can be done later on as well.

Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com>
Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Acked-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Eitan Eliahu <eliahue@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: Define OVS_DPPORT_NUMBER_INVALID

The fields externalVport and internalVport of the OVS_SWITCH_CONTEXT
struct are currently defined as PVOID. However, all over the code they
are used as POVS_VPORT_ENTRY. In order to improve clarity and reduce the
need for useless casts to POVS_VPORT_ENTRY, this patch changes the type
from PVOID to POVS_VPORT_ENTRY.

This patch does not cleanup the code that already uses casts to
POVS_VPORT_ENTRY. This cleanup can be done later on as well.

Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com>
Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Acked-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Eitan Eliahu <eliahue@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: Rename OvsGetVportNo into OvsComputeVportNo and make public

OvsGetVportNo computes a new port number. Therefore, OvsComputeVportNo
is a more clear name for what the function does. Reading OvsGetVportNo
may give the false impression that it returns the port number of an
existing vport.

Also, since the responsibility of assigning dp port numbers no longer
falls on the hyper-v switch port handlers side, but on the netlink vport
commands side (vport add), we will need to use this compute port number
function from outside Vport.c. Therefore, this function declaration is
moved from Vport.c to Vport.h, and becomes public.

Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com>
Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Acked-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Eitan Eliahu <eliahue@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: Rename switch context's nameHashArray and vport's nameLink login register

The field nameLink of the OVS_VPORT_ENTRY is the link within the
OVS_SWITCH_CONTEXT's hash array of vports nameHashArray, hashed by the
ovsName field of the OVS_VPORT_ENTRY.

Later on, the friendly name of the hyper-v switch port will need to be
set from userspace using WMI. This will require that the hyper-v switch
port friendly name be set to the exact string value as the ovs
(datapath) port name set from netlink command vport add.

The vport will need to differentiate between the ovs (datapath) port
name and hyper-v switch port friendly name, because they may differ in
erroneous scenarios, or state differences between the hyper-v switch
port and the ovs (datapath) port. This may happen if the vport was
created by the netlink command vport add, but the VM disconnected (i.e.
the hyper-v switch port was later deleted).

Storing another field in vport, "portFriendlyName" would normally
make the current switchContext->nameHashArray and vport->nameLink
confusing since the "name"-s may be understood to mean the hyper-v
switch port friendly name, or the hyper-v switch port name, when it
actually refers to the ovs (datapath) port name.

Hence, the variable nameHashArray is renamed to ovsPortNameHashArray,
while the nameLink is renamed to ovsPortNameLink. This change will make
a clearer connection between these and the vport field "ovsName" to
which they revolve around.

Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com>
Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Acked-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Eitan Eliahu <eliahue@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: Rename switch context's portHashArray and vport's portLink

The field portLink of the OVS_VPORT_ENTRY is the link within the
OVS_SWITCH_CONTEXT's hash array of vports portHashArray, hashed by the
portId field of the OVS_VPORT_ENTRY.

Later on, we will need to modify the OVS_VPORT_ENTRY so that its port
numbers are set to maximum MAXUINT16. This will require that the field
vportArray of OVS_SWITCH_CONTEXT be removed and replaced with a hash
array, portNoHashArray. Also, a new field, portNoLink, will need to be
added to OVS_VPORT_ENTRY. In order to differentiate between portHashArray
and portNoHashArray, portHashArray is renamed to portIdHashArray. Also,
in order to differentiate between portLink and portNoLink, portLink
is renamed to portIdLink.

In a future patch the vport functionality will be changed to constraint
the port numbers to MAXUINT16.

Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com>
Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Acked-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Eitan Eliahu <eliahue@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: Make VPORT ovs number values smaller than MAXUINT16

For this, the old method of finding vports based on the
ovs port numbers is removed. Now, the lookup of a vport
by ovs port number is done the same way as the lookup by
hyper-v switch port id.

This is done so that the kernel is able to interact with
the userspace correctly when using vport channels.
The problem manifested in lib/dpif-netlink.c, at the function
vport_add_channels.

This patch removes the field vportArray from OVS_SWITCH_CONTEXT.
In its place, portNoHashArray is set. In the OVS_VPORT_ENTRY
struct, we also add portNoLink. This new method will do lookup
and insertions of vports by ovs (datapath) port numbers the same
way it is done for hyper-v switch port ids.

This patch implicitly removes the indexes, which were previously
used in insertions and lookups on ovs port numbers. The removal
of the index also means that the vxlan vport can no longer be
looked up the same way as it was done before: now we hold a pointer
to it, vxlanVport in OVS_SWITCH_CONTEXT. For the moment, we can
have only one vxlan vport. When more will be allowed, this field
will turn into a list of vxlan ports.

The invalid port number value (held in OVS_DPPORT_NUMBER_INVALID)
is now changed from 0 to MAXUINT16, the same as it is on linux.

The function OvsComputeVportNo has also been removed, since the
computation of a vport port number can no longer be done like this.
When vport add will be added, a new, updated OvsComputeVportNo
function will be added.

Also, in OvsInitVportCommon, we no longer need to (and no longer can)
initialize vport->ovsName, nor vport->ovsNameLen, because they will
be initialized by the netlink command vport add. Since the netlink
command vport add will generate numbers for the datapath (ovs) port
numbers and set the port names, we cannot insert the vport into the
hash array of port numbers here, nor into the hash array of port names.

Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com>
Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Acked-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Eitan Eliahu <eliahue@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: Add port friendly name to OVS_VPORT_ENTRY

The port friendly name will be set by WMI / powershell script.
It will be used from within the netlink command vport new to
identify the hyper-v switch port it represents.

This patch also adds a function to lookup a vport by the
port friendly name.

Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com>
Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Acked-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Eitan Eliahu <eliahue@vmware.com>
Acked-by: Nithin Raju <nithin@vmware.com>
Tested-by: Nithin Raju <nithin@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
work on supporting multiple OXMs for different openflow versions
flow: Support OF1.5+ (draft) actset_output field.

This field allows a flow table to match on the output port currently in the
action set.

ONF-JIRA: EXT-233
Signed-off-by: Ben Pfaff <blp@nicira.com>