[ovs-dev] RFC for database statistics interface.

Ben Pfaff blp at nicira.com
Wed Jun 9 10:43:23 PDT 2010


On Wed, Jun 09, 2010 at 08:05:40AM -0700, Keith Amidon wrote:
> On Tue, 08 Jun 2010 18:43:59 -0700, Jeremy Stribling <strib at nicira.com> wrote:
> > The only use case I know is for the controller to poll the stats at a 
> > given interval, but monitor the statistics for delete events (so it can 
> > receive the last known value for the statistics).  So as long as there's 
> > an understanding that the stats provider will update it one last time 
> > before deleting, what you propose will be fine.
> 
> This is the primary use case I've heard discussed as well.  In
> generally, I've been thinking that we need to do everything we can to
> minimize the amount of polling the controllers have to do.  
> 
> For normal rx/tx stats the monitoring for delete case is probably
> sufficient given 64-bit counters.  For error stats however the
> controller may want to know about relatively small changes without
> waiting for what could be a very long polling interval.  A monitor with
> a threshold seems like it would solve this problem nicely.
> 
> All this is a long-winded way of saying that associating a local polling
> interval with each stat and then using that to trigger monitors is
> something I think we should strongly consider.  If the controller could
> set the local polling interval as well as read it (e.g. reduce it from a
> relatively long default) that would be ideal.  

It makes sense for ovs-vswitchd to send a statistics update to the
database for an interface if its error counters are increasing.  I
hadn't thought about that case.  Thank you for bringing it up.

It sounds like a refinement that we could implement without a protocol
change.  The vswitch would locally poll the interfaces at a reasonable
rate (once a second, for example).  If the error counters have
increases, it sends an update to the database process.  No problem.




More information about the dev mailing list