Until now, there were four of these commands: parse-ofp10-actions,
parse-ofp10-instructions, parse-ofp11-actions, parse-ofp11-instructions.
This is painful to add support for new OpenFlow versions and has a ton of
cut-and-paste code. This commit generalizes the code to improve on both
of those points.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
Until now, knowledge about OpenFlow has been somewhat scattered around the
tree. Some of it is in ofp-actions, some of it is in ofp-util, some in
separate files for individual actions, and most of the wire format
declarations are in include/openflow. This commit centralizes all of that
in ofp-actions.
Encoding and decoding OpenFlow actions was previously broken up by OpenFlow
version. This was OK with only OpenFlow 1.0 and 1.1, but each additional
version added a new wrapper around the existing ones, which started to
become hard to understand. This commit merges all of the processing for
the different versions, to the extent that they are similar, making the
version differences clearer.
Previously, ofp-actions contained OpenFlow encoding and decoding, plus
ofpact formatting, but OpenFlow parsing was separated into ofp-parse, which
seems an odd division. This commit moves the parsing code into ofp-actions
with the rest of the code.
Before this commit, the four main bits of code associated with a particular
ofpact--OpenFlow encoding and decoding, ofpact formatting and parsing--were
all found far away from each other. This often made it hard to see what
was going on for a particular ofpact, since you had to search around to
many different pieces of code. This commit reorganizes so that all of the
code for a given ofpact is in a single place.
As a code refactoring, this commit has little visible behavioral change.
The update to ofproto-dpif.at illustrates one minor bug fix as a side
effect: a flow that was added with the action "dec_ttl" (a standard
OpenFlow action) was previously formatted as "dec_ttl(0)" (using a Nicira
extension to specifically direct packets bounced to the controller because
of too-low TTL), but after this commit it is correctly formatted as
"dec_ttl".
The other visible effect is to drop support for the Nicira extension
dec_ttl action in OpenFlow 1.1 and later in favor of the equivalent
standard action. It seems unlikely that anyone was really using the
Nicira extension in OF1.1 or later.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
This allows callers to be more uniform, because they don't have to pick
out whether they should parse actions or instructions based on the OpenFlow
version in use. It also allows the Write-Metadata instruction emulation
in OpenFlow 1.0 to be treated just as in OpenFlow 1.1 in the sense that
it is allowed in contexts where instructions are allowed in OpenFlow 1.1
and not elsewhere. (The changes in the tests reflect this more accurate
treatment.)
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
"apply_actions" is assumed, any other instruction has to be specified
explicitly.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
Normally I would also add documentation for the logging options to the
ovs-appctl manpage, but I am concerned that in this case it would actually
make the manpage confusing, because one of the main purposes of ovs-appctl
is to modify the log levels of *other* programs, and these options only
modify the log level of ovs-appctl itself, which is rarely useful.
The following commit will start using these logging options in a test.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ansis Atteka <aatteka@nicira.com>
This commit introduces multiple appctl commands (dpctl/*)
They are needed to interact with userspace datapaths (dpif-netdev), because the
ovs-dpctl command runs in a separate process and cannot see the userspace
datapaths inside vswitchd.
This change moves most of the code of utilities/ovs-dpctl.c in lib/dpctl.c.
Both the ovs-dpctl command and the ovs-appctl dpctl/* commands make calls to
lib/dpctl.c functions, to interact with datapaths.
The code from utilities/ovs-dpctl.c has been moved to lib/dpctl.c and has been
changed for different reasons:
- An exit() call in the old code made perfectly sense. Now (since the code
can be run inside vswitchd) it would terminate the daemon. Same reasoning
can be applied to ovs_fatal_*() calls.
- The lib/dpctl.c code _should_ not leak memory.
- All the print* have been replaced with a function pointer provided by the
caller, since this code can be run in the ovs-dpctl process (in which
case we need to print to stdout) or in response to a unixctl request (and
in this case we need to send everything through a socket, using JSON
encapsulation).
The syntax is
ovs-appctl dpctl/(COMMAND) [OPTIONS] [PARAMETERS]
while the ovs-dpctl syntax (which _should_ remain the same after this change)
is
ovs-dpctl [OPTIONS] (COMMAND) [PARAMETERS]
Signed-off-by: Daniele Di Proietto <ddiproietto@vmware.com>
[blp@nicira.com made stylistic and documentation changes]
Signed-off-by: Ben Pfaff <blp@nicira.com>
This matches the option offered by some other Open vSwitch daemons. I
intend to use it in tests in an upcoming commit.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Justin Pettit <jpettit@nicira.com>
These 64-bit registers are intended to conform with the OpenFlow 1.5
draft specification.
EXT-244.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
We've had a couple of questions about this lately, including one suggestion
that we should always save the OpenFlow port numbers. This explains why
the behavior is as it is.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Justin Pettit <jpettit@nicira.com>
CMAP_FOR_EACH and CLS_FOR_EACH and their variants tried to use void ** as
a "pointer to any kind of pointer". That is a violation of the aliasing
rules in ISO C which technically yields undefined behavior. With GCC 4.1,
it causes both warnings and actual misbehavior. One option would to add
-fno-strict-aliasing to the compiler flags, but that would only help with
GCC; who knows whether this can be worked around with other compilers.
Instead, this commit rewrites the iterators to avoid disallowed pointer
aliasing.
VMware-BZ: #1287651
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
Now that all the relevant classifier structures use RCU and internal
mutual exclusion for modifications, we can remove the fat-rwlock and
thus make the classifier lookups lockless.
As the readers are operating concurrently with the writers, a
concurrent reader may or may not see a new rule being added by a
writer, depending on how the concurrent events overlap with each
other. Overall, this is no different from the former locked behavior,
but there the visibility of the new rule only depended on the timing
of the locking functions.
A new rule is first added to the segment indices, so the readers may
find the rule in the indices before the rule is visible in the
subtables 'rules' map. This may result in us losing the opportunity
to quit lookups earlier, resulting in sub-optimal wildcarding. This
will be fixed by forthcoming revalidation always scheduled after flow
table changes.
Similar behavior may happen due to us removing the overlapping rule
(if any) from the indices only after the corresponding new rule has
been added.
The subtable's max priority is updated only after a rule is inserted
to the maps, so the concurrent readers may not see the rule, as the
updated priority ordered subtable list will only be visible after the
subtable's max priority is updated.
Similarly, the classifier's partitions are updated by the caller after
the rule is inserted to the maps, so the readers may keep skipping the
subtable until they see the updated partitions.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Hide the cursor from the classifier iteration users and move locking to
the iterators. This will make following RCU changes simpler, as the call
sites of the iterators need not be changed at that point.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
This just makes ovs-benchmark compile on windows.
This lets us go ahead with just a 'make' instead of
picking and choosing executables that are tested to work on
windows as arguments for make.
This commit does not make ovs-benchmark a supported utility
on windows.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
The unit test, "OFPST_TABLE reply - OF1.2" in ofp-print.at
sends a very large hex string as an argument to 'ovs-ofctl ofp-print'.
The length of the hex string exceeds the maximum command line length
in Windows. With this commit, we can pass the same hex string by
placing it inside a file.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Make the parser compatible with how we print group buckets and allow
actions= to be specified, e.g.:
group_id=1,type=all,bucket=actions=output:2,bucket=actions=output:3
Also, better document the supported syntax in the manual page and
cover both syntax formats in the unit test.
Signed-off-by: Thomas Graf <tgraf@noironetworks.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
When a flow with a "learn" action is deleted, one often wants the flows
that it created (the "learned flows") to be deleted as well. This commit
makes that possible.
I am aware of a race condition that could lead to a learned flow not being
properly deleted. Suppose thread A deletes a flow with a "learn" action.
Meanwhile, thread B obtains the actions for this flow and translates and
executes them. Thread B could obtain the actions for the flow before it is
deleted, but execute them after the "learn" flow and its learned flows are
deleted. The result is that the flow created by thread B persists despite
its "learn" flow having been deleted. This race can and should be fixed,
but I think that this commit is worth reviewing without it.
VMware-BZ: #1254021
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Thomas Graf <tgraf@suug.ch>
Acked-by: Ethan Jackson <ethan@nicira.com>
Use OFPRR_GROUP_DELETE as the reason for deleting flows due
to the removal of a group that they use.
This implementation adds an delete_reason member to struct ofputil_flow_mod
as a convenient way to set the reason used by delete_flows__() when it is
called indirectly from delete_group__().
Signed-off-by: Simon Horman <horms@verge.net.au>
[blp@nicira.com initialized the new member in a few more places]
Signed-off-by: Ben Pfaff <blp@nicira.com>
This flag was overlooked when support for the "learn" action was added.
(It was always supported in the OpenFlow code, just not in the ovs-ofctl
interface.)
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Thomas Graf <tgraf@suug.ch>
This is mostly for unit tests that use ovs-ofctl monitor.
service_start() creates a new process and waits till
daemonize_complete() is called by the child.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Otherwise, on Windows unit tests, data sometimes is
not seen in output files.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Since the removal of dispatcher thread, OVS creates 'n-handler-threads'
file descriptors for each bridge port. To allow more bridge ports
be supported, this commit raises the limit on the number of open file
descriptors from 7500 to 65535.
Bug #1254038.
Signed-off-by: Alex Wang <alexw@nicira.com>
Commit a6ce4b9d25 (ofproto-dpif-upcall: Avoid use-after-free in
revalidate() corner case.) showed that it is somewhat tricky to correctly
use the existing dpif flow dumping interface to obtain batches of flows.
One has to be careful about calling dpif_flow_dump_next_may_destroy_keys()
before going on to the next flow.
A better interface is possible, one that is naturally oriented toward
retrieving batches when that is a useful optimization. This commit
replaces the dpif interface by such a design, and updates both the
implementations and the callers to adopt it.
This is a fairly large change, but I think that the code in
ofproto-dpif-upcall is easier to understand after the change.
Signed-off-by: Ben Pfaff <blp@nicira.com>
a425a102-c317-4743-b0ba-79d59ff04a74
Bridge "br0"
[...]
Port test
Interface test
type: vxlan
options: {unknown="1"}
error: "test: could not set configuration (Invalid argument)"
ovs_version: "2.1.90"
Signed-off-by: Thomas Graf <tgraf@redhat.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Store the error condition of a failed port configuration in a new
column 'error' in the Interface table.
Example:
$ ovs-vsctl add-port br0 test -- \
set Interface test type=vxlan options:unknown=1
ovs-vsctl: Error detected while setting up 'test'. [...]
$ ovs-vsctl list Interface test | grep error
error : "test: could not set configuration (Invalid argument)"
Fixing the error will clear the error column:
$ ovs-vsctl set Interface test options:remote_ip=1.1.1.1
$ ovs-vsctl list Interface test | grep error
error : []
$
For now, the high level error messages when opening and configuring
the netdev are used. Further patches can extend passing the error
pointer into the individual netdev implementations to allow for more
fine grained error messages to be stored.
Signed-off-by: Thomas Graf <tgraf@redhat.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The first argument passed to 'sign' command is used as prefix
for both req.pem and cert.pem.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
OpenFlow 1.4 and earlier always send the description of every port in
response to an OFPMP_PORT_DESC request. OpenFlow 1.5 proposes allowing
the controller to request a description of a single port. This commit
implements a prototype.
EXT-69.
Signed-off-by: Ben Pfaff <blp@nicira.com>
OpenFlow 1.4 and earlier always send the description of every group in
response to an OFPMP_GROUP_DESC request. OpenFlow 1.5 proposes allowing
the controller to request a description of a single group. This commit
implements a prototype.
EXT-69.
Signed-off-by: Ben Pfaff <blp@nicira.com>
ovs-ofctl supports using port names in commands that operate on ports. It
does this by connecting to the switch, listing the ports, and picking out
the one with the specified name. However, this didn't work properly for
OpenFlow 1.3+, because it always used an OFPT_FEATURES_REQUEST to list the
ports, and in OpenFlow 1.3+ the reply to this request does not include a
list of ports. This commit fixes the problem (using code that previously
was just a fallback when there were too many ports to fit in an
OFPT_FEATURES_REPLY).
For similar reasons, "ovs-ofctl show" wasn't listing the switch's ports
when it connected to a switch over OpenFlow 1.3 or later. This commit
fixes that bug also.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Conflicts:
utilities/ovs-ofctl.c
A user may set LimitNOFILE through systemd or other means to set
the maximum number of open file descriptors. Only modify the ulimit
if not already set to a higher value by the user.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Gospodarek <gospo@redhat.com>
The Open vSwitch software switch now supports all the required features of
OpenFlow 1.0 through 1.3, with one known trivial exception[*]. Enable them
by default in ovs-vswitchd.
For now, ovs-ofctl only enables OpenFlow 1.0 by default. This is
because ovs-ofctl implements command such as "add-flow" as raw
OpenFlow requests, but those requests have subtly different semantics
in different OpenFlow versions. For example:
- In OpenFlow 1.0, a "mod-flow" operation that does not find any
existing flow to modify adds a new flow.
- In OpenFlow 1.1, a "mod-flow" operation that does not find any
existing flow to modify adds a new flow, but only if the
mod-flow did not match on the flow cookie.
- In OpenFlow 1.2 and a later, a "mod-flow" operation never adds a
new flow.
[*] OpenFlow 1.1, but not any earlier or later version of OpenFlow,
requires support for VLANs introduced by Ethertype 0x88a8, but Open
vSwitch does not support this Ethertype.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Reviewed-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
