On 10/20/22 08:25, Wilson Peng wrote: > From: Wilson Peng <[email protected]> > > The stats is got via function call ofputil_decode_flow_stats_reply() and > for OpenFlow15 it will also call oxs_pull_entry__(). Currently we found on > Windows the counter is incorrect. > > From the output below, it is incorrect for the n_bytes counter via OpenFlow15 > on > CMD ovs-ofctl dump-flows. > > ovs-ofctl.exe -O OpenFlow10 dump-flows nsx-managed | findstr 1500112 > cookie=0x1e77082def43e867, duration=1743781.018s, table=4, n_packets=1500112, > n_bytes=2173860465,… > cookie=0x2033543ed8e89cc1, duration=1743781.018s, table=4, n_packets=1500112, > n_bytes=2173860465,… > > ovs-ofctl.exe -O OpenFlow15 dump-flows nsx-managed | findstr 1500112 > cookie=0x1e77082def43e867, duration=1743728.762s, table=4, n_packets=1500112, > n_bytes=18446744071588444785, … > cookie=0x2033543ed8e89cc1, duration=1743728.762s, table=4, n_packets=1500112, > n_bytes=18446744071588444785, > > With the fix, new compiled ovs-ofctl1.exe could dump the correct n_bytes > counter > Via OpenFlow15 > > ovs-ofctl1.exe -O OpenFlow15 dump-flows nsx-managed | findstr 1500112 > cookie=0x1e77082def43e867, duration=1743719.459s, table=4, n_packets=1500112, > n_bytes=2173860465,… > cookie=0x2033543ed8e89cc1, duration=1743719.459s, table=4, n_packets=1500112, > n_bytes=2173860465, … > > Signed-off-by: Wilson Peng <[email protected]> > --- > lib/ox-stat.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/lib/ox-stat.c b/lib/ox-stat.c > index c6fbb4daa..adec5ba6f 100644 > --- a/lib/ox-stat.c > +++ b/lib/ox-stat.c > @@ -209,10 +209,18 @@ oxs_pull_entry__(struct ofpbuf *b, struct oxs_stats > *stats, > stats->idle_age = ntohll(get_unaligned_be64(payload)) >> 32; > break; > case OXS_OF_PACKET_COUNT: > + #ifdef _WIN32 > + stats->packet_count = ntohll(get_32aligned_be64(payload)); > + #else > stats->packet_count = ntohll(get_unaligned_be64(payload));
Hmm. This is interesting. Though both functions supposed to produce exactly the same result. If that is not happening, then it is a bug in the implementation of get_unaligned_be64(). And that should be fixed instead. There are other places where this function is used, so we can have issues there as well. Looking at the numbers, 2173860465 == 0x 81927a71 18446744071588444785 == 0xffffffff81927a71 For some reason the result produced by get_unaligned_be64() has upper half of bits set to 1. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
