ofproto: Only initiate flow table modifications if they will succeed.

In OpenFlow, a single "flow_mod" operation can change the actions (and
some other properties) of an arbitrary number of flows.  Until now,
Open vSwitch has assumed that any subset of these operations could
fail.  However, it has come out in discussion in the OpenFlow extensibility
working group that "partial failure" of a flow table operation is
undesirable, and furthermore that it should be possible to avoid it on
hardware implementations.  (The latter is the reason that Open vSwitch
permitted it to be with.)

This commit changes Open vSwitch to check whether all of a set of flow
table modifications will succeed before it initiates any of them.
This will not change visible behavior of the Open vSwitch software
switch, which never failed flow table modifications anyway.  It might
change behavior of some hardware implementation, but I don't actually know
of any.

ONF-JIRA: EXT-362.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Thomas Graf <tgraf@suug.ch>

1 files changed, 6 insertions, 2 deletions

diff --git a/include/openflow/nicira-ext.h b/include/openflow/nicira-ext.h
index fe954cdbf..767b98b0a 100644
--- a/include/openflow/nicira-ext.h
+++ b/include/openflow/nicira-ext.h
@@ -2236,8 +2236,9 @@ OFP_ASSERT(sizeof(struct nx_flow_update_full) == 24);
  *     a flow_mod with type OFPFC_MODIFY affects multiple flows, but only some
  *     of those modifications succeed (e.g. due to hardware limitations).
  *
- *     This cannot occur with the current implementation of the Open vSwitch
- *     software datapath.  It could happen with other datapath implementations.
+ *     This cannot occur with the Open vSwitch software datapath.  This also
+ *     cannot occur in Open vSwitch 2.4 and later, because these versions only
+ *     execute any flow modifications if all of them will succeed.
  *
  *   - Changes that race with conflicting changes made by other controllers or
  *     other flow_mods (not separated by barriers) by the same controller.
@@ -2246,6 +2247,9 @@ OFP_ASSERT(sizeof(struct nx_flow_update_full) == 24);
  *     (regardless of datapath) because Open vSwitch internally serializes
  *     potentially conflicting changes.
  *
+ *   - Changes that occur when flow notification is paused (see "Buffer
+ *     Management" above).
+ *
  * A flow_mod that does not change the flow table will not trigger any
  * notification, even an abbreviated one.  For example, a "modify" or "delete"
  * flow_mod that does not match any flows will not trigger a notification.