Fw: [PATCH] pktgen divides by zero on short runs

Fw: [PATCH] pktgen divides by zero on short runs

[Andrew Morton]

Begin forwarded message:

Date: Fri, 5 Sep 2003 01:40:27 -0400 (EDT)
From: Najati Imam <najati@netlab.uky.edu>
To: linux-kernel@vger.kernel.org
Subject: [PATCH] pktgen divides by zero on short runs


On very short runs when computing the packets per second the time that is
used can be zero. For small packets this can happen with as many as 100,
maybe more, packets. The patch below checks the denominator before
dividing and if it is zero puts a notice in the results output that
explains why pbs, bps and mbps are all zero, like so

Result: OK: 10(c10+d0) usec, 1 (64byte,0frags) 0pps 0Mb/sec (0bps) \
  (Time too short to measure) errors: 0

Hope this hasn't already been addressed (it was present in 2.6.0-test4,
which is what I generated the patch from), also this is my first
submission, so if I did it all wrong, I will accept the appropriate
punishment.

Najati Imam




diff -urN linux-2.6.0-test4/net/core/pktgen.c linux-2.6.0-test4-nri/net/core/pktgen.c
--- linux-2.6.0-test4/net/core/pktgen.c 2003-08-22 19:57:49.000000000 -0400
+++ linux-2.6.0-test4-nri/net/core/pktgen.c     2003-09-05 01:15:20.000000000 -0400
@@ -50,6 +50,9 @@
  * Fix refcount off by one if first packet fails, potential null deref, 
  * memleak 030710- KJP
  *
+ * Check for potential div by zero in the event of a really short send time
+ * 030905 NRI 
+ *
  * See Documentation/networking/pktgen.txt for how to use this.
  */
 
@@ -720,9 +723,10 @@
 
        {
                char *p = info->result;
-               __u64 pps = (__u32)(info->sofar * 1000) / ((__u32)(total) / 1000);
+               __u32 tt = ((__u32)(total) / 1000);
+               __u64 pps = (tt) ? (__u32)(info->sofar * 1000) / ((__u32)(total) / 1000) : 0;
                __u64 bps = pps * 8 * (info->pkt_size + 4); /* take 32bit ethernet CRC into account */
-               p += sprintf(p, "OK: %llu(c%llu+d%llu) usec, %llu (%dbyte,%dfrags) %llupps %lluMb/sec (%llubps)  errors: %llu",
+               p += sprintf(p, "OK: %llu(c%llu+d%llu) usec, %llu (%dbyte,%dfrags) %llupps %lluMb/sec (%llubps) %s errors: %llu",
                             (unsigned long long) total,
                             (unsigned long long) (total - idle),
                             (unsigned long long) idle,
@@ -732,6 +736,7 @@
                             (unsigned long long) pps,
                             (unsigned long long) (bps / (u64) 1024 / (u64) 1024),
                             (unsigned long long) bps,
+                            (tt) ? "" : "(Time too short to measure)",
                             (unsigned long long) info->errors
                             );
        }

Re: Fw: [PATCH] pktgen divides by zero on short runs

[David S. Miller]

Andrew, I'm starting to think it's actually your mailer
that's changing the tabs to spaces when you forward other
people's patches to me or the networking lists.

Every forwarded patch you've sent to me or to netdev has
had this problem.  Can you make the forwarded emails
be attachments or similar?  I thought sylpheed did that
by default :)

Re: Fw: [PATCH] pktgen divides by zero on short runs

[Andrew Morton]

"David S. Miller" <davem@redhat.com> wrote:
>
> 
> Andrew, I'm starting to think it's actually your mailer
> that's changing the tabs to spaces when you forward other
> people's patches to me or the networking lists.

Nope, Najati's patch on lkml is all-spaces.

> Every forwarded patch you've sent to me or to netdev has
> had this problem.  Can you make the forwarded emails
> be attachments or similar?  I thought sylpheed did that
> by default :)

I think it's OK...

Re: Fw: [PATCH] pktgen divides by zero on short runs

[David S. Miller]

On Fri, 5 Sep 2003 02:11:01 -0700
Andrew Morton <akpm@osdl.org> wrote:

> Nope, Najati's patch on lkml is all-spaces.

Ok, please tell him to fix his mailer so I can apply
the patches he submits.  You can also tell him to send
such patches to netdev and then you'll never have to
forward patches for him again :)