[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openvswitch-git
Subject:    [ovs-git] Open vSwitch: ofproto: Properly refresh rule modified time when nothing else changes. (mas
From:       dev () openvswitch ! org (dev at openvswitch ! org)
Date:       2013-01-26 1:23:22
Message-ID: E1TyuUM-0003jj-Ob () noxrepo ! org
[Download RAW message or body]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Open vSwitch".

The branch, master has been updated
       via  644e2a7cbd7043a88322177173606f675e55e7d7 (commit)
      from  267e915f526b4102364d92aff4eb9355b8da25ca (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 644e2a7cbd7043a88322177173606f675e55e7d7
Diffs: http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=commitdiff;h=644e2a7cbd7043a88322177173606f675e55e7d7
                
Author: Ben Pfaff <blp at 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 at nicira.com> for helping to track this
down.

Bug #14841.
Reported-by: Hiroshi Tanaka <htanaka at vmware.com>
CC: Amar Padmanabhan <amar at nicira.com>
Signed-off-by: Ben Pfaff <blp at nicira.com>


-----------------------------------------------------------------------

Summary of changes:
 ofproto/ofproto.c |   18 +++++++++---
 tests/learn.at    |   75 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 88 insertions(+), 5 deletions(-)


hooks/post-receive
-- 
Open vSwitch


[prev in list] [next in list] [prev in thread] [next in thread]