Thanks for your reply. I have noticed the procedure of flow expire yet. In this situation, I think, the packet count of the first rule should smaller than the other two, say 52, 54, 54. But in my experiment, I also find some situations in which the packet count of the first rule is bigger than the other two, e.g., 54, 52, 52. I want to know if there is any explanation about this? Thanks!
2015-08-28 0:53 GMT+08:00 Ben Pfaff <[email protected]>: > On Thu, Aug 27, 2015 at 09:48:25AM -0700, Alex Wang wrote: > > On Thu, Aug 27, 2015 at 5:36 AM, hui pang <[email protected]> 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 [email protected] http://openvswitch.org/mailman/listinfo/discuss
