On Thu, Aug 27, 2015 at 09:48:25AM -0700, Alex Wang wrote: > On Thu, Aug 27, 2015 at 5:36 AM, hui pang <pchui2...@gmail.com> wrote: > > > Hi, > > > > I'm attempting to collect packet statistics from flow remove messages. But > > I found some flow statistics are of no consistence. > > > > The topology of my experiment is a linear one, which is generated from "mn > > --topo=linear,5,1". > > i.e., h1 -- s1-eth1 -- s1-eth2 -- s2-eth2 -- s2-eth3 -- s3-eth2 -- s3-eth3 > > -- s4-eth2 -- s4-eth3 -- s5-eth2 -- s5-eth1 -- h5. (some host are ignored). > > And in my experiment, packets are forwarded according to its IPv4 > > destination address. > > Firstly, I inject the following rules to assure every IP packets can be > > forwarded from h1 to h5 without any PacketIn message being triggered. > > > > ---------------------------------------------------------------------------------------- > > switch | rule > > > > ---------------------------------------------------------------------------------------- > > s1 | ip,nw_dst=10.0.0.5,priority=1,actions=output:2 > > s2 | ip,nw_dst=10.0.0.5,priority=1,actions=output:3 > > s3 | ip,nw_dst=10.0.0.5,priority=1,actions=output:3 > > s4 | ip,nw_dst=10.0.0.5,priority=1,actions=output:3 > > s5 | ip,nw_dst=10.0.0.5,priority=1,actions=output:1 > > > > ----------------------------------------------------------------------------------------- > > Secondly, I use traffic generation tool (nping) to inject traffic from h1 > > to h5 (h1 nping -N -udp -g 2000 -p 3000-3600 -delay 0.2 -c 1 10.0.0.5). And > > destination port is also used as an identity. > > Thirdly, I insert new rules on s5 and s3 to count packets directed to h5 > > and with the tos field set to 24, and the hard timeout of those rule is set > > to 30 seconds. Besides, those rules have a priority of 2. > > Finally, I install a new rule on s1 to set the tos field to 24 for all > > traffic toward to 10.0.0.5. Also, this rule have a priority of 2 and its > > hard timeout is set to 10 seconds. > > Those three rules are listed as follows: > > > > ---------------------------------------------------------------------------------------------------------------------------------------- > > switch | rule > > > > ---------------------------------------------------------------------------------------------------------------------------------------- > > s1 | > > ip,nw_dst=10.0.0.5,priority=2,hardtimeout=10,actions=mod_nw_tos=24,output:2 > > s3 | > > ip,nw_dst=10.0.0.5,nw_tos=24,priority=2,hardtimeout=30,actions=output:3 > > s5 | > > ip,nw_dst=10.0.0.5,nw_tos=24,priority=2,hardtimeout=30,actions=output:1 > > > > ----------------------------------------------------------------------------------------------------------------------------------------- > > In general, those three rules should report the same flow statistics after > > their expire, but actually, the first rule (on s1) report a different (at a > > distance of about 1 or 2 packets) packet count and byte count some times. > > For example, the statistics may be: 52 55 55. > > > > Hey, > > Here is my understanding, > > Not sure the version of ovs you used, but say for branch-2.3, the flow > expiration is handled by > ofproto_rule_expire(), which will call delete_flow__()... > > The delete_flow__() will first call ofproto_rule_send_removed() which sends > the flow deletion > notification to any controller, and then actually deletes the flow... > > In other words, when ovs reports the flow deletion, the flow is valid still > there... and we may fail > to include the final stats (between notifying flow deletion and actually > deleting the flow in > datapath)... > > Ben, do you think we should address this?
It's hard to get statistics that are perfect in all cases without hurting performance. It's not usually that important. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
