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>
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>
