I agree, it seems like a separate issue. With the new failure, the stats
are all accounted for, but are attributed to different ports than expected
(possibly because the packets are actually going across the different
port). The previous one caused stats to be omitted.
On 26 April 2014 10:12, Ale
Acked-by: Alex Wang
And applied,
On Fri, Apr 25, 2014 at 3:12 PM, Alex Wang wrote:
> It is even harder to reproduce the new failure, rarer than the flow-dumps
> one. Just ran into this once in my life...
>
> More importantly, the flow-dumps pkt counts are sync'ed in the failed case.
>
> Fro
It is even harder to reproduce the new failure, rarer than the flow-dumps
one. Just ran into this once in my life...
More importantly, the flow-dumps pkt counts are sync'ed in the failed case.
>From my understanding, this new issue, relates to reading stats from
netdev-dummy, which is different
found this in the morning, will keep investigating,
./learn.at:362: (ovs-ofctl dump-ports br0 2; ovs-ofctl dump-ports br0 3) |
sed 's/ (xid=0x[0-9a-fA-F]*)//'
--- - 2014-04-25 01:25:43.022048477 -0700
+++ /root/openvswitch/tests/testsuite.dir/at-groups/328/stdout 2014-04-25
01:25:43.01771189
i'll kick an overnight run on "learning action - self-modifying flow with
idle_timeout".~ (seq 1). if it survives, tmr morning,
i'll ack it~~
On Thu, Apr 24, 2014 at 10:26 PM, Joe Stringer wrote:
> revalidate_ukey() had a bug where it would update the ukey->stats even
> if it decided not to
revalidate_ukey() had a bug where it would update the ukey->stats even
if it decided not to push stats (as an optimisation). ukey->stats should
only be updated when those stats are pushed.
This bug would arise in the following situation:
* A flow has been dumped before.
* The flow needs to be reva
