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>
OpenFlow 1.5 (draft) extends the OFPAT_SET_FIELD action originally
introduced in OpenFlow 1.2 so that it can set not just entire fields but
any subset of bits within a field as well. This commit adds support for
that feature when OpenFlow 1.5 is used.
With this feature, OFPAT_SET_FIELD becomes a superset of NXAST_REG_LOAD.
Thus, this commit merges the implementations of the two actions into a
single ofpact_set_field.
ONF-JIRA: EXT-314
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
The init function is not allowed to call into the kernel datapath
while running unit tests since the kernel datapath is not loaded.
Instead of making the function dummy, it is better to not have it
at all.
Reported-by: Gurucharan Shetty <gshetty@nicira.com>
Signed-off-by: Nithin Raju <nithin@vmware.com>
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
OVSDB has the concept of "immutable" columns, which are columns whose
values are fixed once a row is inserted. Until now, ovs-vsctl has not
allowed these columns to be modified at all. However, this is a little too
strict, because these columns can be set to any value at the time that the
row is inserted. This commit relaxes the ovs-vsctl requirement, then, to
allow an immutable column's value to be modified if its row has been
inserted within this transaction.
Requested-by: Mukesh Hira <mhira@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Add the following files:
meta-flow.inc
nx-match.inc
to lib/.gitignore
Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This patch ensures that the friendly port name has no more than 16 characters
and also if it is not in use.
The method which checks the WMI jobs has been updated in order to provide
relevant error codes/descriptions.
Methods retrieving the according VM and VM network adapter mapped to an OVS
port have been added as well. They are called:
Get-VMNetworkAdapterByOVSPort
Get-VMByOVSPort
Example of usage:
2 import-module .\OVS.psm1
3 $vnic = Get-VMNetworkAdapter test_2_1
4 $vnic[0] | Set-VMNetworkAdapterOVSPort -OVSPortName ovs-port-1
5 $vnic[1] | Set-VMNetworkAdapterOVSPort -OVSPortName ovs-port-1
6 $vnic[0] | Set-VMNetworkAdapterOVSPort -OVSPortName ovs-port-2
7 $vnic[1] | Set-VMNetworkAdapterOVSPort -OVSPortName ovs-port-1
8 Get-VMNetworkAdapterByOVSPort ovs-port-1
9 Get-VMByOVSPort ovs-port-2
Signed-off-by: Lucian Petrut <lpetrut@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>
Commit 3e5aeeb581 (bridge: Keep bond active slave selection across OVS
restart) updated the OVS schema number from 7.9.0 to 8.0.0. However,
the major version number should only be incremented for incompatible schema
changes, ones that are likely to break software that interacts with the
schema. The change in question only added a column to a table, so it is
not an incompatible change. Therefore, this commit changes the schema
version number to 7.10.0, indicating a compatible change.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
The OpenFlow 1.5 (draft) Copy-Field action has two OXM headers, one after
the other. Until now, Open vSwitch has implemented these as a pair of
ovs_be32 members, which meant that only 32-bit OXM could be supported. This
commit changes the implementation to use nx_pull_header(), which means that
in the future when that function supports 64-bit experimenter OXMs,
Copy-Field will automatically get that support too.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
This improves the general abstraction of OXM/NXM by eliminating direct
knowledge of it from the meta-flow code and other places.
Some function renaming might be called for; for example, mf_oxm_header()
may not be the best name now that the function is implemented within
nx-match. However, these renamings would make this commit larger and
harder to review, so I'm postponing them.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
NXM/OXM are only supposed to put 1-bits in a value if the corresponding bit
in the mask is a 1-bit, but in the case of cookie matching, e.g.
ovs-ofctl del-flows br0 cookie=0x3/0x1
ovs-ofctl would encode a bad OXM. This fixes the problem.
(The test "ofproto - del flows based on cookie mask" in the OVS testsuite
tickles this bug.)
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
This will acquire its first user in an upcoming commit.
This implementation is not optimized at all but it doesn't matter for the
purpose for which I intend to initially use it.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
This is a first step toward improving the abstraction of OXM and NXM in the
tree. As an immediate improvement, this commit removes all of the
definitions of the OXM and NXM constants from the top-level header files,
because they are no longer used anywhere.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
Replace bitwise loops with a single operation, inline all bitmap
functions. Inlining allows the compiler to remove unnecessary code
due to some parameters being compile-time constants.
Before:
$ tests/ovstest test-bitmap benchmark 1000000
bitmap equal: 341 ms
bitmap scan: 8089 ms
After:
$ tests/ovstest test-bitmap benchmark 1000000
bitmap equal: 152 ms
bitmap scan: 146 ms
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Co-authored-by: Kmindg <kmindg@gmail.com>
Acked-by: Ben Pfaff <blp@nicira.com>
It seemed awkward to have declarations outside the for loop.
This may also be a little faster because it avoids some calls to
count_1bits(). The idea for that change is due to Jarno Rajahalme
<jrajahalme@nicira.com>.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
I found the BFD transmit interval was lowerbounded by the default value
without warning, although documentation does not consider a lowerbound.
Testing has been performed with transmit and receive intervals as low as 1
ms, and although CPU overhead was effected (especially with multiple BFD
sessions such as 6 and higher), it worked well.
Signed-off-by: Niels van Adrichem <n.l.m.vanadrichem@tudelft.nl>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Using the compiler intrinsic shows approximately around 25% speed
up with some classifier specific unit tests.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Correct the old comment like ofpbuf_reserve() to describe the expected
behavior of ofpbuf_reserve_with_tailroom().
Signed-off-by: Wang Sheng-Hui <shhuiw@gmail.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The return type of ofpbuf_tail() and ofpbuf_end() is pointer, not byte.
Signed-off-by: Wang Sheng-Hui <shhuiw@gmail.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Primary goals of netdev-windows.c are:
1) To query the 'network device' information of a vport such as MTU, etc.
2) Monitor changes to the 'network device' information such as link
status.
In this change, we implement only #1. #2 can also be implemented, but it
does not seem to be required for the purposes of implement
'ovs-dpctl.exe show'.
Signed-off-by: Nithin Raju <nithin@vmware.com>
Acked-by: Ankur Sharma <ankursharma@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 add a lib/netdev-windows.c which mostly contains stub
code and in subsequent patches, would use the netlink interface to query
netdev information for a vport.
The code implements netdev functionality for "internal" and "system"
types of vports.
Signed-off-by: Nithin Raju <nithin@vmware.com>
Acked-by: Ankur Sharma <ankursharma@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 define netlink family, attributes and commands
for query the 'network device' information of VPORTs, such as
MTU, Link status, etc.
I considered adding the netdev command to the OVS_WIN_CONTROL_FAMILY
itself, but the netdev attributes are not compatible with the existing
attributes for the events. I also considered adding new attributes to
the VPORT family, but we'll have to extend the standard datapath
interface for that.
In this patch, we fix the definition of 'OVS_WIN_CONTROL_ATTR_MAX' as
well.
Signed-off-by: Nithin Raju <nithin@vmware.com>
Acked-by: Ankur Sharma <ankursharma@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>
Batching the cmap find improves the memory behavior with large cmaps
and can make searches twice as fast:
$ tests/ovstest test-cmap benchmark 2000000 8 0.1 16
Benchmarking with n=2000000, 8 threads, 0.10% mutations, batch size 16:
cmap insert: 533 ms
cmap iterate: 57 ms
batch search: 146 ms
cmap destroy: 233 ms
cmap insert: 552 ms
cmap iterate: 56 ms
cmap search: 299 ms
cmap destroy: 229 ms
hmap insert: 222 ms
hmap iterate: 198 ms
hmap search: 2061 ms
hmap destroy: 209 ms
Batch size 1 has small performance penalty, but all other batch sizes
are faster than non-batched cmap_find(). The batch size 16 was
experimentally found better than 8 or 32, so now
classifier_lookup_miniflow_batch() performs the cmap find operations
in batches of 16.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
This makes the following patch easier and cleans up the code.
Explicit "inline" keywords seem necessary to prevent performance
regression on cmap_find() with GCC 4.7 -O2.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
We use the 'counter' as a "lock" providing acquire-release
semantics. Therefore we can use normal, non-atomic access to the
memory accesses between the atomic accesses to 'counter'. The
cmap_node.next needs to be RCU, so that can not be changed.
For the writer this is straightforward, as we first acquire-read the
counter and after all the changes we release-store the counter. For
the reader this is a bit more complex, as we need to make sure the
last counter read is not reordered with the preceding read operations
on the bucket contents.
Also rearrange code to benefit from the fact that hash values are
unique in any bucket.
This patch seems to make cmap_insert() a bit faster.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
The test cases have been carefully crafted so that we do the same
amount of "overhead" operations in each case. Earlier, with no
mutations, the number of random number generations was different for
hmap and cmap test cases. hmap test was also missing an ignore() call.
Now the numbers look like this:
$ tests/ovstest test-cmap benchmark 2000000 8 0
Benchmarking with n=2000000, 8 threads, 0.00% mutations:
cmap insert: 597 ms
cmap iterate: 65 ms
cmap search: 299 ms
cmap destroy: 251 ms
hmap insert: 243 ms
hmap iterate: 201 ms
hmap search: 299 ms
hmap destroy: 202 ms
So it seems search on cmap can be as fast as on hmap in the
single-threaded case.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
We already update the count field as the last step of these functions,
so returning the current count is very cheap. Callers that care about
the count become a bit more efficient, as they avoid extra
non-inlineable function call.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Previously we masked labels not present in the incoming packet.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Should index the first lse for all parts of the lse (label, TC, BOS).
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
