[ovs-dev] [PATCH] Allow sFlowCpInterval=0 to disable counter samples, and fix bug in sampler removal.

Neil McKee neil.mckee at inmon.com
Fri Feb 12 00:59:04 UTC 2010


Please see below  -- suggested fixes for a couple of relatively minor issues in the sFlow library.
I include the patch as an attachment too,  in case my mailer garbles the lines.

Regards,
Neil

---
 lib/sflow_poller.c  |   27 +++++++++++++++++++++++----
 lib/sflow_sampler.c |    7 +++++--
 2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/lib/sflow_poller.c b/lib/sflow_poller.c
index ffd09d3..e7dc2b1 100644
--- a/lib/sflow_poller.c
+++ b/lib/sflow_poller.c
@@ -68,10 +68,29 @@ u_int32_t sfl_poller_get_sFlowCpInterval(SFLPoller *poller) {
 
 void sfl_poller_set_sFlowCpInterval(SFLPoller *poller, u_int32_t sFlowCpInterval) {
     poller->sFlowCpInterval = sFlowCpInterval;
-    /* Set the countersCountdown to be a randomly selected value between 1 and
-       sFlowCpInterval. That way the counter polling would be desynchronised
-       (on a 200-port switch, polling all the counters in one second could be harmful). */
-    poller->countersCountdown = 1 + (random() % sFlowCpInterval);
+    if(sFlowCpInterval) {
+        /* Set the countersCountdown to be a randomly selected value between 1 and
+	   sFlowCpInterval. That way the counter polling will be desynchronised
+	   (on a 200-port switch, polling all the counters in one second could be harmful).
+	   In a large network, even this might not be ideal if time-synchroniziation
+	   between devices is close and counters are always polled on second boundaries. If
+	   1000 different devices all send an sFlow datagram on the same second boundary
+	   it could result in an antisocial burst.
+	   However when counter-samples are packed into the export datagram they do not
+	   always result in that datagram being sent immediately. It is more likely that
+	   a subsequent packet-sample will be the one that triggers the datagram to be sent.
+	   The packet-sample events are not sychronized to any clock, so that results in
+	   excellent desynchronization (http://blog.sflow.com/2009/05/measurement-traffic.html).
+	   Another smoothing factor is that the tick() function called here is usually
+	   driven from a fairly "soft" polling loop rather than a hard real-time event.
+	*/
+        poller->countersCountdown = 1 + (random() % sFlowCpInterval);
+    }
+    else {
+        /* Setting sFlowCpInterval to 0 disables counter polling altogether.  Thanks to
+	   Andy Kitchingman for spotting this ommission. */
+        poller->countersCountdown = 0;
+    }
 }
 
 /*_________________---------------------------------__________________
diff --git a/lib/sflow_sampler.c b/lib/sflow_sampler.c
index 759b5a2..c2b4556 100644
--- a/lib/sflow_sampler.c
+++ b/lib/sflow_sampler.c
@@ -16,14 +16,17 @@ void sfl_sampler_init(SFLSampler *sampler, SFLAgent *agent, SFLDataSource_instan
     SFLDataSource_instance dsi = *pdsi;
 
     /* preserve the *nxt pointer too, in case we are resetting this poller and it is
-       already part of the agent's linked list (thanks to Matt Woodly for pointing this out) */
+       already part of the agent's linked list (thanks to Matt Woodly for pointing this out,
+       and to Andy Kitchingman for pointing out that it applies to the hash_nxt ptr too) */
     SFLSampler *nxtPtr = sampler->nxt;
+    SFLSampler *hashPtr = sampler->hash_nxt;
   
     /* clear everything */
     memset(sampler, 0, sizeof(*sampler));
   
-    /* restore the linked list ptr */
+    /* restore the linked list and hash-table ptr */
     sampler->nxt = nxtPtr;
+    sampler->hash_nxt = hashPtr;
   
     /* now copy in the parameters */
     sampler->agent = agent;
-- 
1.5.3.3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Allow-sFlowCpInterval-0-to-disable-counter-samples.patch
Type: application/octet-stream
Size: 3632 bytes
Desc: not available
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20100211/66912047/attachment-0004.obj>
-------------- next part --------------

----
Neil McKee
InMon Corp.
http://www.inmon.com





More information about the dev mailing list