Most hypervisors have no use for this column, so populating it just wastes
CPU time. It can still be enabled explicitly via other-config.
CC: Peter Balland <peter@nicira.com>
CC: David Tsai <dtsai@nicira.com>
Bug #5961.
NIC-397.
This pointer arithmetic caused a warning on sparc. One alternative would
be to add a cast through "void *", but it seems at least as reasonable to
just use a few macros to do direct assignments.
In an effort to make CFM easier to understand and configure, this
patch removes the Maintenance_Point and Monitor tables from the
database. As a consequence, users will only be able to configure
one remote maintenance point. Furthermore, before this patch each
remote maintenance point maintained its own separate fault flag in
the database. This flag is no longer reported, users will need to
infer the fault status from the global CFM fault flag.
These settings added complexity to the database and CFM module
interface with negligible benefit. This patch removes them in such
a way that they can easily be re-added in the (unlikely) event that
we need them in the future.
This patch moves the cfm/show unixctl show command from the bridge
to the CFM module. This is more in line with how LACP does it, and
will make future patches easier to implement.
This patch moves miimon logic from the bond module to netdev-linux.
This greatly simplifies the bonding code while adding minimal
complexity to netdev-linux. The bonding code is so high level, it
really has no business worrying about how precisely slave status is
determined.
I know already that this breaks the statsfixes that were implemented by the
following commits:
827ab71c97 "ofproto: Datapath statistics accounted twice."
6f1435fc8f "ofproto: Resubmit statistics improperly account during..."
These were already broken in a previous merge. I will work on a fix.
The recent merge of "master" added a new bond_stable_ids member to
struct ofproto_bundle_settings, but neglected to initialize it. This fixes
the problem.
Found and verified using valgrind.
In some circumstances the bridge can't find a stable physical Ethernet
address to use, so until now it has just picked a random Ethernet address.
In these circumstances, therefore, the bridge Ethernet address would change
from one ovs-vswitchd run to another. But OVS does have a stable
identifier for a bridge: its UUID. This commit changes to use that as the
default bridge Ethernet address.
The datapath ID is sometimes derived from the bridge Ethernet address, so
this change also makes the bridge Ethernet address more stable.
CC: Natasha Gude <natasha@nicira.com>
Bug #5594.
In addition to the changes to ofproto, this commit changes all of the
instances of "struct flow" in the tree so that the "in_port" member is an
OpenFlow port number. Previously, this member was an OpenFlow port number
in some cases and an ODP port number in other cases.
This eliminates the final reference from bridge.c directly into the dpif
layer, which will make it easier to change the implementation of ofproto
to support other lower layers.
Until now, ofproto has used a mix of datapath and OpenFlow port numbers in
its client interface. This commit changes it to use OpenFlow port numbers
exclusively, to raise the level of abstraction.
Most of this commit boils down to simple search-and-replace with a few
call to ofp_port_to_odp_port() sprinkled in. The addition of ofproto_port
is one exception. An ofproto_port is almost the same as a dpif_port; the
difference is just that its port number is an OpenFlow port number instead
of a datapath port number.
Until now, packet processing in ovs-vswitchd has been split between two
components: ofproto, for basic OpenFlow functionality, and bridge, for
OFPP_NORMAL processing. This architecture will not work as Open vSwitch
starts to support a wider variety of underlying hardware, because it
imposes a model in which the bridge needs to be able to look at every
exact-match flow within a OpenFlow flow, which most hardware doesn't
support.
Therefore, this commit moves all of the packet processing code in
bridge into ofproto, as preparation for generalizing further.
Previously, if --private-key or another option that requires SSL support
was used, but OVS was built without OpenSSL support, then OVS would fail
with an error message that the specified option was not supported. This
confused users because it made them think that the option had been removed:
http://openvswitch.org/pipermail/discuss/2011-April/005034.html
This commit improves the error message: OVS will now report that it was
built without SSL support. This should be make the problem clear to users.
Reported-by: Aaron Rosen <arosen@clemson.edu>
Feature #5325.
It doesn't make sense to create a QoS object without any queues.
Before this patch, OVS would configure the QoS object and as a
result drop all traffic going through the affected interface. With
this patch, OVS will simply clear QoS configuration on the
interface.
Bug #5583.
This commit creates a new heartbeat mode for LACP. This mode
treats LACP as a protocol simply for monitoring link status. It
strips out most of the sanity checks built into the protocol.
Addition of this mode makes "lacp-force-aggregatable" and
"lacp-strict" options obsolete so they are removed.
Stable bonding mode needs an ID to guarantee consistent slave
selection decisions across ovs-vswitchd instances. Before this
patch, we used the lacp-port-id for this purpose. However, LACP
places restrictions on how lacp-port-ids can be allocated which may
be inconvenient. This patch creates a special purpose
bond-stable-id other_config setting which allows users to tweak
this value directly.
This makes ofproto use the term "port" consistently for a single
purpose (which is unfortunately different from the term "interface"
used in the OVS database, but at least it is now internally
consistent).
This loses the bridge_run_one() before iface_configure_cfm(), which means
that CFM configuration can now take two reconfigurations in a row. That's
a regression that we had earlier, which had been fixed previously by commit
392730c42b "bridge: Run once before configuring CFM". It will, however,
be fixed again in a later commit.
The bridge_get_all_ifaces() function is rather odd. It creates an shash
index over the "struct iface"s within a bridge, but there's already an
index over them (the 'iface_by_name' hmap in struct bridge) that the
iface_lookup() function searches. The only value it adds is to put the
names of bond fake ifaces into the index, but that's hardly worth it. We
can just search the existing hash table as needed, instead.
The bridge_fetch_dp_ifaces() function is also odd. It fetches the entire
mapping from port number to name from the dpif again, although this has
already been done twice already. We can just merge this in with the second
iteration.
This commit makes both of those changes.
This is more convenient for looking up a bridge by name. That makes
reconfiguration a little bit simpler, because there is no longer a need to
build a temporary index of existing bridges. I don't see any downsides.
The main reason that iterate_and_prune_ifaces() existed was because it was
somewhat inconvenient to iterate across all of the interfaces, especially
if anything needed to be deleted. Now that we've switched from arrays to
lists and hmaps, it's a bit easier, and certainly it's easier to read code
when there aren't any callbacks involved, so inline what this was doing.
This was the only remaining caller of iterate_and_prune_ifaces() so this
removes that function as well as the callback.
Users will the ability to manually set aggregation keys on a
per-slave basis in order to use some of the more advanced LACP
features. Most notably, LACP controlled active-backup bonding
requires fine grained aggregation key configuration.
In some extremely advanced situations, one may want to force
non-bondable slaves to advertise themselves as bondable. This
patch adds that capability.
Also includes some minor code cleanup.
These new semantics are less efficient in the case where the flood_vlans
actually changed, but that should be very rare.
There are no advantages to this change on its own, but upcoming commits
will add multiple layers between the code supplying the flood_vlans and
actually calling mac_learning_set_flood_vlans(). Consistency in this
multilayered interface seems valuable, and the rest of it does not transfer
ownership from the caller to the callee.
This improves the abstraction behind ofproto and connmgr.
Some of this could even go into fail_open, but I'm not sure that it would
make anything easier to understand.
A bond slave has a pointer to its iface's netdev, so we don't want it to
keep that pointer after the bridge closes the netdev.
This is becoming a bit of a mess so perhaps we need reference counting for
netdevs (although Jesse didn't like the idea when I proposed it before).
Until now, ovs-vswitchd has been unable to configure IP addresses and
routes for bridges whose Bridge records lack a Port and an Interface
record for the bridge's local port (e.g. OFPP_LOCAL, the port with the
same name as the bridge itself). When such a bridge was reconfigured,
ovs-vswitchd would output a log message that worried people.
This commit fixes the internal limitation that led to the message being
printed.
Bug #5385.
Mirrors that output to ports will be destroyed when their output ports are
destroyed, but mirrors that output to VLANs ("RSPAN" mirrors) don't get
automatically destroyed like this and we need to take care of them in a
separate loop.
Extremely advanced users may want fine grained control over the
LACP port and system IDs of a bond. This would be extremely
unusual for the average user, so this patch puts the configuration
parameters in other_config of the relevant tables.
When LACP negotiations are unsuccessful, OVS falls back to standard
balance-slb bonding. In some cases, users may want to require
successful LACP negotiations for any slaves to be enabled at all.
This patch implements a new "strict" mode which disables all slaves
when LACP negotiations are unsuccessful.
The logic here did not make sense. A packet arriving on a port is mirrored
if the port is a mirroring source port AND (not OR) the packet is in one of
the VLANs that is mirrored.
This test has been here since the mirroring code was introduced. It seems
to me that it was never correct.
