Extend the key and tunnel key conversion to nested NL format functions use the
NL attribute as a parameter so we can use them for missed packet formatting.
Add functions for calculating the space needed for storing the key and the
tunnel key in NL format
Signed-off-by: Eitan Eliahu <eliahue@vmware.com>
Acked-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Nithin Raju <nithin@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This reverts commit d2064437e2, which
fails clang thread satefy analysis.
A more complete patch will be introduced later.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
classifier_find_rule_exactly() only needs the mutex to protect the
list traversal. Subtables are already RCU protected.
Locking here can be eliminated completely when RCU list is available.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
OvsReadEventCmdHandler was calling OvsRemoveEventEntry after acquiring
CtrlLock. OvsRemoveEventEntry in turn also tries to acquire the same lock.
Added a new lock in Event.c for the eventQueue.
Signed-off-by: Ankur Sharma <ankursharma@vmware.com>
Acked-by: Eitan Eliahu <eliahue@vmware.com>
Acked-by: Sorin Vinturis <svinturis@cloudbasesolutions.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Commit cc377352d (ofproto: Reorganize in preparation for direct
dpdk upcalls.) introduced the bug that keeps reference to 'struct
flow' defined on the stack inside while loop when running out of
the scope. This causes strange bug like wrong mask extraction
when the part of memory is corrupted, and could lead to even
more serious bug/crash.
This commit fixes the above issue by defining an array of the
'struct flow's on the function stack.
Found by running ovs on RHEL7.
Signed-off-by: Alex Wang <alexw@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
According to RFC 7047, 'ephemeral' annotation does not guarantee
the values to be durable. This fix Removes this annotation.
VMware-BZ: 1332235
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Alex Wang <alexw@nicira.com>
classifier already provides lockless lookups, and protected
modifications. When user wants to remove a flow, we currently require
the flow to exist in the classifier. To be thread safe, this requires
the caller to introduce their own mutex, lock it before a lookup, and
then issue classifier_remove() while the lock is still held.
This patch relaxes the "existence requirement" of the rule in
classifier_remove(), allowing it to be called on a rule that may have
already been removed from the classifier. This allows users to do a
classifier_lookup() and classifier_remove() without additional
syncronization.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
On ArchLinux "python" points to 3.x version and the right
2.x python binary is "python2.7".
Signed-off-by: Dmitry V. Krivenok <krivenok.dmitry@gmail.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
I applied the patches for the new vport add workflow that is out for
review, and found that some of the existing code in OvsGetExtInfoIoctl()
needs to be updated. In this patch, we add a CPP called
USE_NEW_VPORT_ADD_WORKFLOW and add the fixes under
USE_NEW_VPORT_ADD_WORKFLOW == 1. The current value is set to 0, since
the vport add code is not checked in yet.
Sending out this patch to unblock the vport add code when it gets checked
in. There are other fixes also required, but they are being addressed as
part of the review comments for vport-add.
Signed-off-by: Nithin Raju <nithin@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
In this change, we add support for the 'OVS_DP_CMD_NEW' netlink command
in the kernel. We don't really support creation of a new datapath. If
the name of the userspace is the same as the single datapath we support,
we return EEXIST.
This code is required to bootstrap ovs-vswitchd which makes the
following sequence of calls:
open_dpif_backer() -> dpif_create_and_open() -> dpif_create()
We also rename HandleDpTransaction() to HandleDpTransactionCommon().
Signed-off-by: Nithin Raju <nithin@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Until now, with GCC, get_unaligned_be64() had an interface that accepted
a "ovs_be64 *", and with other compilers its accepted any
pointer-to-64-bit type, but not void *. This commit fixes the problem,
making the interface the same in both cases.
This fixes a build error on MSVC:
lib/nx-match.c(320) : error C2100: illegal indirection
lib/nx-match.c(320) : error C2034: 'build_assert_failed' : type of bit
field too small for number of bits
lib/nx-match.c(320) : error C2296: '%' : illegal, left operand has
type 'void *'
lib/nx-match.c(320) : error C2198: 'ntohll' : too few arguments for call
It might appear that this patch changes get_unaligned_u64() but in fact
it onloy moves it earlier in the file (since it is now called from the
non-GCC fork of the #if).
Reported-by: Alin Serdean <aserdean@cloudbasesolutions.com>
Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Add a case for the gcc flag fno-strict-aliasing into cccl
Under MSVC Strict aliasing is off by default.
Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Some of the Nicira extension actions include fixed-size 32-bit members that
designate NXM fields. These actions can't accommodate 64-bit experimenter
OXMs, so we need to figure out some kind of solution. This commit does
that, in different ways for different actions.
For some actions, I did not think it was worthwhile to worry about
experimenter OXM, so I just disabled use of them. This is what I did for
bundle, learn, and multipath actions.
Other actions could be gracefully reinterpreted to support experimenter
OXM. This is true of reg_move, which use NXM headers only at the end of
the action and such that using an experimenter OXM would make the action
longer (which unambigously signals to older OVS that the action is an
error, which is desired behavior since older OVS cannot interpret this
action). The stack push and pop actions are also in this category.
reg_load was the most frustrating case. In OpenFlow 1.5 we had already
eliminated this action in favor of OF1.5+ set_field. In other OpenFlow
versions, though, reg_load is more powerful than set_field because it
can modify partial fields. This commit therefore adds a new variant of
reg_load, called reg_load2, which is simply OF1.5+ set_field with a Nicira
extension header on it.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
OpenFlow 1.2+ defines a means for vendors to define vendor-specific OXM
fields, called "experimenter OXM". These OXM fields are expressed with a
64-bit OXM header instead of the 32-bit header used for standard OXM (and
NXM). Until now, OVS has not implemented experimenter OXM, and indeed we
have had little need to do so because of a pair of special 32-bit OXM classes
grandfathered to OVS as part of the OpenFlow 1.2 standardization process.
However, I want to prototype a feature for OpenFlow 1.5 that uses an
experimenter OXM as part of the prototype, so to do this OVS needs to
support experimenter OXM. This commit adds that support.
Most of this commit is a fairly straightforward change: it extends the type
used for OXM/NXM from 32 to 64 bits and adds code to encode and decode the
longer headers when necessary. Some other changes are necessary because
experimenter OXMs have a funny idea of the division between "header" and
"body": the extra 32 bits for experimenter OXMs are counted as part of the body
rather than the header according to the OpenFlow standard (even though this
does not entirely make sense), so arithmetic in various places has to be
adjusted, which is the reason for the new functions nxm_experimenter_len(),
nxm_payload_len(), and nxm_header_len().
Another change that calls for explanation is the new function mf_nxm_header()
that has been split from mf_oxm_header(). This function is used in actions
where the space for an NXM or OXM header is fixed so that there is no room
for a 64-bit experimenter type. An upcoming commit will add new variations
of these actions that can support experimenter OXM.
Testing experimenter OXM is tricky because I do not know of any in
widespread use. Two ONF proposals use experimenter OXMs: EXT-256 and
EXT-233. EXT-256 is not suitable to implement for testing because its use
of experimenter OXM is wrong and will be changed. EXT-233 is not suitable
to implement for testing because it requires adding a new field to struct
flow and I am not yet convinced that that field and the feature that it
supports is worth having in Open vSwitch. Thus, this commit assigns an
experimenter OXM code point to an existing OVS field that is currently
restricted from use by controllers, "dp_hash", and uses that for testing.
Because controllers cannot use it, this leaves future versions of OVS free
to drop the support for the experimenter OXM for this field without causing
backward compatibility problems.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
OXM renamed the 'vendor' field from NXM to the 'class', and uses the term
"experimenter", which OVS usually renders as "vendor" for historical
reasons, as part of the extended 64-bit OXMs. To reduce confusion, this
commit adopts the OXM terminology for class.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
