ofproto: Properly refresh rule modified time when nothing else changes.
authorBen Pfaff <blp@nicira.com>
Fri, 25 Jan 2013 23:07:36 +0000 (15:07 -0800)
committerBen Pfaff <blp@nicira.com>
Sat, 26 Jan 2013 01:21:29 +0000 (17:21 -0800)
commit644e2a7cbd7043a88322177173606f675e55e7d7
treec345161204446214e9582b35c7e27c2bc347a312
parent267e915f526b4102364d92aff4eb9355b8da25ca
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/ofproto.c
tests/learn.at