On Sat, May 24, 2014 at 6:06 PM, Madhu Challa <cha...@noironetworks.com> wrote: > Hi Jesse, > > Thanks for the clarifications. > > > On Fri, May 23, 2014 at 9:52 AM, Jesse Gross <je...@nicira.com> wrote: >> >> On Thu, May 22, 2014 at 5:02 PM, Madhu Challa <cha...@noironetworks.com> >> wrote: >> > I am looking at adding support for On-demand flow counters and figured >> > one >> > of the benefits of doing this is reduced lock contention in >> > ovs_flow_stats_update. >> > >> > If my understanding is correct, this involves processing flags >> > OFPFF13_NO_PKT_COUNTS and OFPFF13_NO_BYT_COUNTS and communicating them >> > so >> > when the kernel flows are created / updated we somehow pass this info >> > along >> > so the stats do not get updated for such flows. >> >> It's not clear that this is really the case. OVS still needs to >> maintain stats in order to age out idle flows, etc. even if they >> aren't used by the controller. > > > I was making this assumption based on the comments in the TODO list. > > " * On-demand flow counters. I think this might be a real optimization in > some cases for the software switch. > [optional for OF1.3+]" > > I would guess the last used field is the one needed to age out the flows, > but if we also have to increment the counters we would need the lock and > there would not be much savings I can think of.
My guess is that even just maintaining the last used field would be about the same. One other data point is that moving from per-CPU to per-NUMA stats didn't appear to have much effect on performance even for flows on different cores in the same socket, which would indicate that maybe there isn't much overhead here after all. It would be fairly easy to test out the potential performance gain by simply not updating the stats in the kernel at all and see what happens. I would try that before doing the work to plumb everything through. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
