ofproto: Optimise OpenFlow flow expiry

Optimise OpenFlow flow expiry by placing expirable flows on a list.
This optimises scanning of flows for expiry in two ways:

* Flows that will never expire are not traversed.

  This addresses a case seen in the field.  With 1,000,000 flows that
  are not expirable, this dramatically reduces CPU utilization to
  approximately zero.

* Empirically list traversal appears faster than the code it replaces.

  With 1,000,000 expirable flows present an otherwise idle system I
  observed CPU utilisation of around 20% with the existing code but
  around 10% with this new code.

Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
rhel: Automatically start openvswitch service before bringing an ovs interface up or down

This patch modifies the ifup/ifdown scripts to automatically
start the openvswitch service before ovs-vsctl is invoked thus
not making it mandatory to auto-start openvswitch on boot.

Signed-off-by: Thomas Graf <tgraf@redhat.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
rhel: Add OVSREQUIRES to automatically bring up OpenFlow interface dependencies

The use of OpenFlow controllers may require for a subset of
the network (typically the management network intrerface) to be
brought up before the openvswitch service is started.

The newly introduced key "OVSREQUIRES" allows to specify a
list of interfaces that need the be brought up before the
openvswitch service is autostarted. It is also possible to
build a chain of bridge dependencies.

	TYPE=OVSBridge
	OVSREQURIES="em1"
	[...]

A special UPPEDSTACK var that is passed along avoids getting
lost in dependency loops.

Signed-off-by: Thomas Graf <tgraf@redhat.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
dpif-linux: Report dropped lost messages at WARN level.

Messages about packets being lost are logged at level WARN, but when
they were generated at a high rate, those consolidated messages were
logged at ERR.  This changes to consolidated messages to be logged at
WARN, too.

Thanks to Ben Pfaff for quickly suggesting the culprit.

Bug #14783

Reported-by: James Schmidt <jschmidt@nicira.com>
Signed-off-by: Justin Pettit <jpettit@nicira.com>
linux: Increase accuracy of ingress_policing_rate at low rates

The current method of calculating the ingress policer rate
can lead to inaccuracy if ingress_policing_rate is set to
a smallish values because the rate is divided by 8 first
which causes rounding errors.

Signed-off-by: Thomas Graf <tgraf@redhat.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
vconn: Initialize 'recv_any_version' member of struct vconn in vconn_init().

This uninitialized data caused failures in the test "ofproto -
eviction upon table overflow (OpenFlow 1.2)" for some developers and in
some circumstances.

Found by valgrind.

Reported-by: Justin Pettit <jpettit@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
ofproto: Properly refresh rule modified time when nothing else changes.

In Open vSwitch, a "modify" or "modify_strict" flow_mod is supposed to
refresh the flow's last-modified time even if nothing else changes, because
this interpretation makes the "learn" action more useful.  As commit
308881afb (ofproto: Reinterpret meaning of OpenFlow hard timeouts with
OFPFC_MODIFY.) notes:

    I finally found a good use for hard timeouts in OpenFlow, but they
    require a slight reinterpretation of the meaning of hard timeouts.
    Until now, a hard timeout meant that a flow would be removed the
    specified number of seconds after a flow was created.  Intervening
    modifications with OFPFC_MODIFY(_STRICT) had no effect on the hard
    timeout; the flow would still be deleted the specified number of
    seconds after its original creation.

    This commit changes the effect of OFPFC_MODIFY(_STRICT).  Now,
    modifying a flow resets its hard timeout counter.  A flow will time out
    the specified number of seconds after creation or after the last time
    it is modified, whichever comes later.

However, commit 080437614b (ofproto: Represent flow cookie changes as
operations too.) broke this behavior because it incorrectly optimized out
"modify" operations that didn't change the flow's actions or flow cookie.
This commit fixes the problem, and adds a test to prevent future
regression.

Thanks to Amar Padmanabhan <amar@nicira.com> for helping to track this
down.

Bug #14841.
Reported-by: Hiroshi Tanaka <htanaka@vmware.com>
CC: Amar Padmanabhan <amar@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
ofproto: Maintain "expirable" list for "add" flow_mod with replaced rule.

Commit e503cc199 (ofproto: Optimise OpenFlow flow expiry) optimized
OpenFlow flow expiration by putting expirable flows on a list, but it
failed to remove flows from the list when they were replaced by a new
flow with an OpenFlow flow_mod "add" operation.  This commit fixes the
problem.

Found by valgrind.

CC: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
datapath: Clear struct ovs_key_ipv4_tunnel padding.

Following patch memset ovs_key_ipv4_tunnel padding area so that
packets from a flow would be mapped to same flow in kernel datapath
flow table.

Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Bug #14843
worker: Don't have worker abort when parent dies.

Depending on how forcefully the parent process is killed, the worker
could abort when trying to read or write on their shared socket.  This
changes those errors from VLOG_ABORT to VLOG_FATAL so that a core isn't
generated.

Bug #14821

Reported-by: Amey Bhide <abhide@nicira.com>
Signed-off-by: Justin Pettit <jpettit@nicira.com>