Until now, by default the IDL replicated all tables and all columns in the
database, and a few functions made it possible to avoid replicating
selected columns. This commit adds a mode in which nothing is replicated
by default and the client code is responsible for specifying each column
and table that it is interested in. The following commit adds a user for
this mode.
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.
None of the existing callers of ofproto_add_flow() want an idle timeout,
but ofproto_add_flow() was giving them a 5-second timeout anyway. I don't
know how this worked properly--in-band will patiently add the flow back
every few seconds anyway, but the bridge doesn't do that.
Also add an explanatory comment to ofproto_add_flow().
I'm retaining the "managers" column in the Open_vSwitch table for now, but
I hope that applications transition to using "manager_options" eventually
so that we could drop it.
CC: Andrew Lambeth <wal@nicira.com>
CC: Jeremy Stribling <strib@nicira.com>
Currently netdev_get_carrier() returns both a carrier status and
an error code. However, usage of the error code was inconsistent:
most callers either ignored it or didn't perform their task if an
error occured, which prevented bond rebalancing. This makes the
handling consistent by translating an error into a down status in
the netdev library.
Bug #3959
Until now, when ovs-vswitchd dropped interfaces because of duplicate names,
it would not write -1 to the ofport column in the OVSDB record for the
interface, which made it appear that the interface was still active (if
it had been before). This commit fixes the problem.
This commit also sets ofport to -1 for interfaces that cannot be created
for other reasons.
In-band control is always enabled when a manager is configured. Some
applications wish to control all the flows within a bridge, and in-band
control can override that wish. Depending on how the network is
configured, this can lead to loops as the in-band control rules try to
learn where to send traffic.
This commit adds a "disable-in-band" key to the "other_config" column of
bridge tables. If set to "true", in-band will be disabled regardless of
manager or controller configuration.
There's no need to have a mask in this action, because both parts of the
TCI are part of the flow structure.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
When bridge.c decides to flood a packet as the result of a "normal"
flow action, it now checks whether each port is configured to
receive flood packets.
Bug #3741
This allows eliminating padding from odp_flow_key, although actually doing
that is postponed until the next commit.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
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>
Jesse pointed out that port_changed_cb isn't a great interface. It's only
around because, earlier, we had a lousy interface for monitoring netdev
status, so that we needed to pass along information obtained by ofproto
into the bridge. But netdev_monitor is now sufficiently sophisticated that
the bridge can set up an independent netdev_monitor without any important
loss of efficiency. Since this makes the code cleaner, this commit does
so.
Until now, a command that removed and added ports in a single change to
the database, e.g.:
ovs-vsctl del-port br0 vif1.0 -- add-port br0 vif2.0
typically failed, because of this sequence of events:
1. Bridge code removes vif1.0 from br0.
2. Bridge code adds vif2.0 to br0.
3. ofproto_run() receives kernel notification that vif1.0 was deleted, so
it notifies the bridge by calling back to bridge_port_changed_ofhook_cb,
which sees that it has an interface with the specified port number, and
deletes it. Oops--this is where the problem occurs. For completeness:
4. ofproto_run() receives kernel notification that vif2.0 was added, so
it notifies the bridge by calling back to ,
which sees that it has no interface with the specified port number, and
does nothing.
This commit fixes the problem by making bridge_port_changed_ofhook_cb() not
care about ports being dropped. This is a corner case that we shouldn't
work too hard to care about, since it can only happen if an administrator
is meddling with datapaths using ovs-dpctl, and the consequences are simply
that packets directed to that device will take longer to be rerouted to
another device (it will take a while for the MAC learning table to time out
the entry). Basically, the admin gets what he deserves.
Thanks to Jesse Gross for identifying the problem.
Bug #3671.
The previous commit arranged to always open the netdev for bridge ports
within the loop that adds new ports to datapaths. So now the additional
attempt to open them within the following loop is superfluous and
presumably will always fail. This commit drops it and merges two
iterations through bridge ports into a single one, since the first is now
trivial.
Until now, if the type of a bridge port changed in the database, then
ovs-vswitchd would report an error and keep it the same type. This commit
changes the behavior to something more reasonable: the old datapath port is
deleted and replaced by a new datapath port of the correct type.
iface_cfg is also available as iface->cfg, so there's no benefit in also
passing it as a separate parameter.
Also, get rid of the one-liner reconfigure_iface() function that wasn't
helping with anything.
The main advantage of a sparse array over a hash table is that it can be
iterated in numerical order. But the OVS implementation of sparse arrays
is quite expensive in terms of memory: on a 32-bit system, a sparse array
with exactly 1 nonnull element has 512 bytes of overhead. In this case,
the sparse array's property of iteration in numerical order is not
important, so this commit converts it to a hash table to save memory.
Header caching speeds up sending tunneled traffic by bypassing the Linux
IP stack. This also causes it to bypass IPsec processing, which will
break connectivity. This commit disables header caching when IPsec is
enabled.
This is intended to provide controllers enough information to determine
whether a switch is overloaded or busted, to enable them to spread load
fairly across a group of switches.
Feature #2421.
CC: Peter Balland <peter@nicira.com>
All of these changes avoid using the same name for two local variables
within a same function. None of them are actual bugs as far as I can tell,
but any of them could be confusing to the casual reader.
The one in lib/ovsdb-idl.c is particularly brilliant: inner and outer
loops both using (different) variables named 'i'.
Found with GCC -Wshadow.
The current date in milliseconds since the epoch is ~1,282,841,552,000,
which is greater than LONG_MAX of 4,294,967,295 on 32-bit systems, so
no matter what was stored into bond_next_fake_iface_update, it would always
appear to be expired. It really needs to be a 64-bit number. (This was
just a typo really.)
Since XenServer 5.5 requires --fake-proc-net, this probably fixes an
important bug there.
Reported-by: Luiz Henrique Ozaki <luiz.ozaki@gmail.com>
Not replicating unneeded columns has some value in avoiding CPU time and
bandwidth to the database. In ovs-vswitchd, setting cur_cfg as write-only
also have great value in avoiding extra reconfiguration steps. When
ovs-vsctl is used in its default mode this essentially avoids half of the
reconfigurations that ovs-vswitchd currently does. What happens now is:
1. ovs-vsctl updates the database and increments next_cfg.
2. ovs-vswitchd notices the change to the database, reconfigures
itself, then increments cur_cfg to match next_cfg.
3. The database sends the change to cur_cfg back to ovs-vswitchd.
4. ovs-vswitchd reconfigures itself a second time.
By not replicating cur_cfg we avoid step 3 and save a whole reconfiguration
step.
Also, now that the database contains interface statistics, this avoids
reconfiguring every time that statistics are updated.
Commit e96a4d8035 "bridge: Feed flow stats into learning table." started
feeding flow statistics back into the learning table, but it did not
distinguish between flows with and flows without an action that outputs to
OFPP_NORMAL. Flows without such an action are not put into the learning
table initially, because bridge_normal_ofhook_cb() is not called for them,
but since that commit they have been put into the learning table when their
flows are reassessed.
This is inconsistent--flows without OFPP_NORMAL should either be learned
from all the time or never, not sometimes. I can see valid arguments both
ways, but since it was always my intention not to learn from such flows,
this commit disables learning from them.
Problem found by code inspection. I don't know of any observed bug that
this fixes.
Until now, the ovs-vswitchd main loop has refreshed keys and certificates
from their files only when the database changes. This works fine if new
keys and certificates are installed with new file names, because the update
to the database to point to the new files will cause them to be read. But
if the new keys and certificates are copied over the existing files, then
the delay until they are read is indefinite.
This commit fixes the problem by changing the SSL configuration so that it
is rechecked on every trip through the ovs-vswitchd main loop.
Bug #2921.
OpenSSL is picky about the order in which keys and certificates are
changed: you have to change the certificate first, then the key. It
doesn't document this, but deep in the source code, in a function that sets
a new certificate, it has this comment:
/* don't fail for a cert/key mismatch, just free
* current private key (when switching to a different
* cert & key, first this function should be used,
* then ssl_set_pkey */
Brilliant, guys, thanks a lot.
Bug #2921.
Don't act as a learning switch when the fail-mode is "secure" and no
controllers are defined. This allows the bridge to come up in a state
where it won't pass any traffic until a controller has told it to do so.
Configuration of the fail-mode was an attribute of the Controller table.
However, it makes more sense as an attribute of the Bridge table, since
the behavior defines what a bridge should do if it can't connect to
*any* controller. This commit makes the move.
An OpenFlow controller is normally associated with a bridge. It was
possible to define a default controller in the Open_vSwitch table that
would be used if one was not associated with a bridge. This was seldom
used and mostly just caused confusion. This commit removes that
support, so an OpenFlow controller must always be associated with a
bridge.
Adding a macro to define the vlog module in use adds a level of
indirection, which makes it easier to change how the vlog module must be
defined. A followup commit needs to do that, so getting these widespread
changes out of the way first should make that commit easier to review.
A "feature" that ovs-vswitchd inherited from its previous form of
configuration is that every mirror has a name. Names are not necessarily
meaningful, and there is no reason that they should be unique. But the
existing implementation depends on them being unique within a given
bridge, and if they are not drops one of the duplicates.
This commit drops the uniqueness requirement. Instead, it distinguishes
mirrors based on UUID alone.
This commit does not drop the concept of names for mirrors. There is no
technical reason to retain them, but it is possible that users find them
useful for management reasons. The names appear in log messages related
to mirrors, which may make the messages easier to understand.
Bug #2416.
Before, it was possible for records in the configuration database to
disappear, so all of the ovsrec pointers inside bridge structures had
comments cautioning against their use except during reconfiguration. But
now that the bridge has direct control over when ovsdb_idl_run() is called,
it can ensure that bridge_reconfigure() is always called immediately
whenever the IDL data structures change. That means that we can use the
ovsrec configuration at any time after the reconfiguration process
initializes them, not just during reconfiguration.
Until now, the ovs-vswitchd main loop has managed the connection to the
database. This worked adequately until now, but upcoming patches will tie
the bridge code more tightly to the database, which means that the bridge
needs more control over interaction with the database connection and thus
that it is better for the bridge to handle that connection itself. This
commit makes the latter change, moving the database interaction from the
ovs-vswitchd main loop into bridge.c.
