| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
The hidden rules created by in-band control and fail-open should not be
included in the table stats reported via OpenFlow. I seem to recall that
this was done correctly in some previous version but it has broken since
then. This commit fixes the problem and adds a test that should make it
harder to break again in the future.
Reported-by: Ashok Chippa <a.n.chippa@gmail.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
|
| |
|
|
|
|
|
|
|
|
| |
The comments on in_band_rule_check() were more or less wrong (the return
value was no longer used to determine whether a flow could be set up).
This commit fixes the comments and refactors the interface to make better
sense in the current context.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Until now, datapath ports and openflow ports were both represented by
unsigned integers of various sizes. With implicit conversions, etc., it is
easy to mix them up and use one where the other is expected. This commit
creates two typedefs, ofp_port_t and odp_port_t. Both of these two types
are marked by "__attribute__((bitwise))" so that sparse can be used to
detect any misuse.
Signed-off-by: Alex Wang <alexw@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch, when in band control was enabled, every DHCP
packet had to be sent to userspace to calculate it's actions.
Those DHCP packets intended for the local port would have a special
action added to ensure they actually make it there. This
unnecessarily complicates the code, so this patch takes a slightly
different approach. When in-band is enabled, *all* DHCP packets
must be sent to the local port. This guarantees that
xlate_actions() returns the same result every time for a given
flow.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
|
| |
|
|
|
|
|
|
|
| |
In the switch to a single datapath, the simple mapping between
OFPP_LOCAL and OVSP_LOCAL was broken. Unfortunately, a couple of
translations were missed, so this commit fixes them.
Reported-by: Jesse Gross <jesse@nicira.com>
Signed-off-by: Justin Pettit <jpettit@nicira.com>
|
| |
|
|
|
|
|
|
| |
Replaced all instances of Nicira Networks(, Inc) to Nicira, Inc.
Feature #10593
Signed-off-by: Raju Subramanian <rsubramanian@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
| |
|
|
|
|
|
| |
Patch below fixes build on FreeBSD; tested on 10.0-CURRENT.
Signed-off-by: Edward Tomasz Napierala <trasz@FreeBSD.org>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in_band_destroy() doesn't remove all of the rules that in-band control
adds (and it cannot, because that might require waiting for an existing
asynchronous flow modification or addition to complete), so turning on
other-config:disable-in-band or deleting all of the OpenFlow controllers
did not delete all of the in-band rules.
This commit fixes the problem by making the in-band control object hang
around until all of the flows that it set up have actually been deleted.
This problem was introduced as part of commit 7ee20df "ofproto: Implement
asynchronous OFPT_FLOW_MOD commands."
Reported-by: Brad Hall <brad@nicira.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some switching hardware takes a very long time to update its forwarding
rules, up to hundreds of milliseconds. It is undesirable for Open
vSwitch to block waiting this long for individual OpenFlow flow table
modification commands to complete. This commit enables ofproto to queue
up any number of independent flow table operations with asynchronous
completion.
I tested earlier versions of this commit using the "ofproto/clog" and
"ofproto/unclog" commands that it implements in the software switch
implementation. I have not tested the current version very much at all.
CC: Casey Barker <crbarker@google.com>
CC: Rajiv Ramanathan <rajivr@google.com>
|
| |
|
|
|
| |
This removes a lot of code from ofproto.c and makes the ofproto code
easier to understand.
|
| |
|
|
|
|
|
|
|
| |
Back in 2008 or so, I introduced this extension as a way to provide
information about switch status to the new "switch UI" program. Since
then, the switch UI program has been removed and the important information
that was provided by the switch status extension is now available in the
database, so we might as well get rid of this extension, and that is what
this commit does.
|
| |
|
|
|
|
|
| |
Currently the type of the datapath action length is mixture of
size_t and unsigned int. However, size_t is really defined as an
unsigned long, which causes the build to fail on 64-bit platforms.
This consistently uses size_t.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In the medium term, we plan to migrate the datapath to use Netlink as its
communication channel. In the short term, we need to be able to have
actions with 64-bit arguments but "struct odp_action" only has room for
48 bits. So this patch shifts to variable-length arguments using Netlink
attributes, which starts in on the Netlink transition and makes 64-bit
arguments possible at the same time.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
|
| |
|
|
|
|
|
|
| |
Until now, in-band control traffic has always gone to the default queue,
typically queue 0. It makes sense to be able to assing control traffic to
its own queue, so this commit enables that.
Bug #3653.
|
| |
|
|
|
|
|
|
|
|
| |
When userspace and the kernel were using the same structure for flows,
flow_t was a useful way to indicate that a structure was really a userspace
flow instead of a kernel one, but now it's better to just write "struct
flow" for consistency, since OVS doesn't use typedefs for structs
elsewhere.
Acked-by: Jesse Gross <jesse@nicira.com>
|
| |
|
|
|
|
| |
Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Jesse Gross <jesse@nicira.com>
|
| |
|
|
|
|
|
|
|
| |
Until now the in-band code has taken an rconn (recently, multiple rconns)
and used its remote IP address as the one for which to set up flows. But
we also need to support in-band control to the OVSDB manager, and OVSDB
does not use rconns. This commit takes the first step toward this support
by generalizing the in-band code to take an arbitrary number of (IP,port)
pairs as remotes for which to set up flows.
|
| | |
|
| | |
|
| | |
|
|
|
These names are more meaningful, so we prefer them.
|
