OPENFLOW-1.1+: EXT-187/OF1.4 Flow Monitors Are Under Development

I am unsure if it is appropriate to annotate OPENFLOW-1.1+ in this way
but I wish to throw my hat into the ring for work on EXT-187/OF1.4
flow monitors.

Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
ofproto: Merge do_add_flow() and oftable_insert_rule() into add_flow().

Each of these functions had only a single caller, and breaking them out as
separate functions didn't seem to many the code clearer.

I added a new function meter_insert_rule(): oftable_insert_rule() had used
members of struct meter directly, which worked because it was after the
definition of struct meter.  So there was a choice to either move the
definition of struct meter earlier or add a helper function; I chose the
latter.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Thomas Graf <traf@suug.ch>
ofproto: Add missing lock annotations on prototypes.

Clang only does lock annotation checks based on annotations that are
already visible, so for best results they need to be on prototypes as
well as definitions.

Signed-off-by: Ben Pfaff <blp@nicira.com>
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>
ofproto: Make ofproto_rule_is_hidden() public, and rename.

I'd like to use this from connmgr.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Thomas Graf <tgraf@suug.ch>
ofproto: Move logic for collecting read-only rules into rule_criteria.

ofproto supports OpenFlow tables that the controller can view but not
modify.  Until now, the logic for this was separately implemented in each
flow table operation, which meant that it was somewhat error-prone and in
fact seems missing entirely for "delete" operations.  This commit
implements the "modify" and "delete" side of that logic in the common code
for collecting a group of rules to work on, thereby slightly simplifying
the somewhat tricky modify_flows__() function and fixing the bug in
deletion.

There isn't a good way to reuse this logic for "add" operations.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Thomas Graf <tgraf@suug.ch>
ofproto: Combine "struct ofconn *" and "const struct ofp_header *" args.

It's nicer to pass around a single argument than a pair of them.  This
will also make it easier to change the 'const struct ofp_header *request'
parameters to 'ovs_be32 xid' ones in an upcoming commit.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Thomas Graf <tgraf@suug.ch>
ofproto: Do straightforward removal of asynchronous flow operations.

Open vSwitch has supported datapaths that cannot update their flow tables
synchronously for many versions.  In that time, I have talked to many
hardware implementers.  None of them has ever mentioned the asynchronous
interface.  Furthermore, the only public hardware implementation of an Open
vSwitch datapath (from Centec), does not use the asynchronous interface.

At the same time, the asynchronous interface makes ofproto hard to read and
hard to understand.  It also makes it hard to maintain and extend.  An
extension in an upcoming commit would be very difficult to implement
asynchronously.

Therefore, this commit begins to remove the asynchronous interface.  This
initial commit does only the most straightforward parts of the removal, the
ones that do not significantly change the structure of the code.  For
example, this commit does not remove the ofoperation or ofopgroup data
structures at the core of the asynchronous interface, but instead reduces
them to a vestigial form: where previously an ofoperation might span
multiple trips through the main loop (if the operation were truly
asynchronous), now it always completes immediately.

The following commit will do more structural changes.  It will also update
all the comments, which are mostly left alone here.

The hope is that this structuring of the asynchronous removal into two
stages will make it easier to understand and review.  If not, the commits
could be squashed.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
ofproto: Additional simplifications.

This commit finishes the removal of asynchronous flow table operations
begun in the previous commit, by removing ofoperation and ofopgroup
entirely and all of the code that depended on them.  Following this commit,
all the internal documentation and comments should again be consistent and
correct.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
ofproto: Shrink struct rule_actions slightly.

Nothing actually used 'provider_meter_id', but some code did want to know
whether there was a meter, so we can save a little space by using a bool
instead.  An upcoming commit will add a second bool member.  This change
allows that bool to be added without using extra space.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
ofproto: Reduce duplication in deletion logic.

The delete_flow__() function had two callers, each of which had to
correctly call ofmonitor_flush() when completely done.  An upcoming commit
will add another function that the callers need to call.  This is easier
if delete_flow__() only has one caller, so this commit refactors so that
it does, and inlines delete_flow__() into that caller for further
simplification.

Also remove a parameter from delete_flows__() that wasn't really needed
and change its return type to void since it can't ever fail.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Thomas Graf <tgraf@suug.ch>
Acked-by: Ethan Jackson <ethan@nicira.com>
Implement learned flow deletion.

When a flow with a "learn" action is deleted, one often wants the flows
that it created (the "learned flows") to be deleted as well.  This commit
makes that possible.

I am aware of a race condition that could lead to a learned flow not being
properly deleted.  Suppose thread A deletes a flow with a "learn" action.
Meanwhile, thread B obtains the actions for this flow and translates and
executes them.  Thread B could obtain the actions for the flow before it is
deleted, but execute them after the "learn" flow and its learned flows are
deleted.  The result is that the flow created by thread B persists despite
its "learn" flow having been deleted.  This race can and should be fixed,
but I think that this commit is worth reviewing without it.

VMware-BZ: #1254021
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Thomas Graf <tgraf@suug.ch>
Acked-by: Ethan Jackson <ethan@nicira.com>