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>
FAQ: Add entry describing upgrade order between userspace and kernel.

There will be significant changes for tunneling between 1.9 and 1.10
so this describes how to smoothly upgrade.

Suggested-by: Ben Pfaff <blp@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
datapath: Remove support for Don't Fragment inheritance.

Inheritance of the Don't Fragment bit in tunnels will not be
supported with flow based tunneling and has already been removed
from userspace.  This removes the corresponding kernel support.

Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Kyle Mestery <kmestery@cisco.com>
datapath: Remove tunnel path MTU discovery support.

Path MTU discovery can improve tunnel performance in some cases
but is non-standard and can introduce problems in others.  As a
result it has already been deprecated and removed from userspace.
This removes the corresponding kernel support to simplify the
code.

Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Kyle Mestery <kmestery@cisco.com>
datapath: Remove vport MAC address configuration.

The ability to retrieve and set MAC addresses on vports is only
necessary for tunnel ports (the addresses for actual devices can be
retrieved through direct Linux mechanisms).  Tunnel ports only used
the information for the purpose of generating path MTU discovery
packets, which has now been removed.  Current userspace code already
reflects these changes, so this drops the functionality from the
kernel.

Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Kyle Mestery <kmestery@cisco.com>
datapath: Remove tunnel configuration sequence number.

When tunnel header caching was in use, it was necessary to detect
configuration changes that would invalidate the cache.  This was
done using a sequence number on the configuration.  However, now
that header caching has been removed the sequence number is no
longer necessary.

Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Kyle Mestery <kmestery@cisco.com>
datapath: Remove compatibility GRE identifier.

We want to move the GRE vport ID into the upstream range but in
order to ease the transition kept the old ID around for one release.
This removes the old value.

Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Kyle Mestery <kmestery@cisco.com>
datapath: Remove kernel patch ports.

Now that userspace implements patch ports completely internally,
it's possible to remove the kernel implementation of them.

Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Kyle Mestery <kmestery@cisco.com>