Hi, Ilya, Thanks for the comments. V2 patch is sent out for review. And It is also verified on Windows with the v2 patch.
Regards Wilson From: Ilya Maximets <i.maxim...@ovn.org> Date: Thursday, October 20, 2022 at 19:31 To: Wilson Peng <twofish...@hotmail.com>, d...@openvswitch.org <d...@openvswitch.org> Cc: i.maxim...@ovn.org <i.maxim...@ovn.org>, Wilson Peng <pweis...@vmware.com> Subject: Re: [ovs-dev] [PATCH v1 1/1] lib: Correct the stats of packet_count and byte_count on Windows ⚠ External Email On 10/20/22 08:25, Wilson Peng wrote: > From: Wilson Peng <pweis...@vmware.com> > > 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 <pweis...@vmware.com> > --- > 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. ________________________________ ⚠ External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
