This patch reapplies the changes that were reverted with the commit 59efa47
(Revert DSCP update changes.). It also addresses the problem introduced by
the original commits, cd8fca2 ((jsonrpc: Correctly setting the dscp value
before reconnect.) and b2e18d (No need to restart DB / OVS on changing
dscp value.), that caused numerous unit test failures on some systems (as
diagnosed by valgrind).
With this change there is no need to restart the DB or OVS on configuring a
different value for the manager or controller connection respectively. On
detecting a change in the dscp value on the socket, the previous socket is
closed and a new socket is created and connection is established with the new
configured dscp value.
Signed-off-by: Mehak Mahajan <mmahajan@nicira.com>
This reverts commit cd8fca2ba0 (jsonrpc:
Correctly setting the dscp value before reconnect.) and commit
b2e18db292 (No need to restart DB / OVS on
changing dscp value.), which on some systems causes numerous unit test
failures that valgrind diagnoses as:
Conditional jump or move depends on uninitialised value(s)
at 0x805F63F: jsonrpc_session_set_dscp (jsonrpc.c:1061)
by 0x804F45D: ovsdb_jsonrpc_server_set_remotes (jsonrpc-server.c:417)
by 0x804B775: reconfigure_from_db (ovsdb-server.c:656)
by 0x804C231: main (ovsdb-server.c:159)
Signed-off-by: Ben Pfaff <blp@nicira.com>
With this change there is no need to restart the DB or OVS on configuring a
different value for the manager or controller connection respectively. On
detecting a change in the dscp value on the socket, the previous socket is
closed and a new socket is created and connection is established with the new
configured dscp value.
Signed-off-by: Mehak Mahajan <mmahajan@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>
The changes allow the user to specify a separate dscp value for the
controller connection and the manager connection. The value will take
effect on resetting the connections. If no value is specified a default
value of 192 is chosen for each of the connections.
Feature #10074
Requested-by: Rajiv Ramanathan <rramanathan@nicira.com>
Signed-off-by: Mehak Mahajan <mmahajan@nicira.com>
Open vSwitch already handles a few different protocol variations, but it
does so in a nonuniform manner:
- OpenFlow 1.0 and NXM flow formats are distinguished using the NXFF_*
constant values from nicira-ext.h.
- The "flow_mod_table_id" feature setting is maintained in ofproto as
part of an OpenFlow connection's (ofconn's) state.
There's no way to easily communicate this state among components. It's
not much of a problem yet, but as more protocol support is added it seems
better to have an abstract, uniform way to represent protocol versions and
variants. This commit implements that by introducing a new type
"enum ofputil_protocol". Each ofputil_protocol value represents a variant
of a protocol version. Each value is a separate bit, so a single enum
can also represent a set of protocols, which is often useful as well.
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
I looked at almost every uint<N>_t in the tree to determine whether it was
really in network byte order, and converted the ones that were.
The only remaining ones, modulo my mistakes, are in openflow.h. I'm not
sure whether we should convert those, because there might be some value
in remaining close to upstream for this header.
I've never heard of anyone actually using controller discovery.
It adds a great deal of code to the source tree, and a little
bit of complication to ofproto, so this commit removes it.
ovs-vswitchd writes only the duration of its connection to or disconnection
from each controller to the database. This changes that behavior to write the
time since both the last connection and disconnection events regardless of
connection state. This mirrors the new behavior for reporting database manager
connection status.
Requested-by: Peter Balland <peter@nicira.com>
Bug #4833.
ovs_queue doesn't seem very useful; it's just a singly-linked list. It's
more generally useful to use a general-purpose "struct list" for lists of
packets, so this commit adds such a member to "struct ofpbuf" and shifts
the existing users to use it.
Until now, log messages about OpenFlow connections have named the target
of the connection, e.g. "tcp:1.2.3.4:5555", but they have not named the
datapath. Most often, every datapath has the same target, so this can
make it difficult to tell which connection is going wrong. Usually, that
isn't important, because all connections with the same target will have the
same problems, but it's probably better to be more informative.
This commit changes the log messages to include the datapath name, so that
"tcp:1.2.3.4:5555" becomes, e.g., "xenbr0<->tcp:1.2.3.4:5555".
Requested-by: Keith Amidon <keith@nicira.com>
The 'name' argument to these functions is actively unhelpful, because none
of the callers provided a better name than the one provided by
vconn_get_name(). So drop it.
When the switch is configured to connect to a controller that accepts
connections, waits a few seconds, and then disconnects without setting up
flows, currently this causes "fail-open" to flush the flow table and
stop setting up new flows during the connection duration. This is OK if
it happens once, but it can easily happen every 8 seconds with typical
backoff settings, and that isn't so great.
This commit changes fail-open to only flush the flow table once the switch
appears to have been admitted by the controller, which prevents these
frequent network interruptions.
Thanks to Jesse Gross for especially valuable feedback.
QA notes: Behavior in fail-open and especially behavior with a controller
that rejects the switch after it connects needs to be re-tested. The
ovs-controller --mute switch added by this commit is one simple way to
create such a controller.
CC: Peter Balland <peter@nicira.com>
Bug #1695. Bug #2055.
Previously, rconn and vconn only allowed users to find out about the
remote IP address. This set of changes allows users to retrieve the
remote port, local IP, and local port used for the connection.
