netdev
[Top] [All Lists]

[PATCH,RFC] pktgen sleeping/timing rework

To: Lennert Buytenhek <buytenh@xxxxxxxxxxxxxx>
Subject: [PATCH,RFC] pktgen sleeping/timing rework
From: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Sat, 11 Dec 2004 00:07:33 +0100
Cc: robert.olsson@xxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20041210222058.GA5984@xxxxxxxxxxxxxxxxx>
References: <20041210222058.GA5984@xxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
Lennert Buytenhek writes:
 > 
 > Below is a patch against your latest pktgen devel version which does
 > the following:
 > - Remove usage of get_cycles(), mhz calibration, pg_cycles_per_*,
 >   getRelativeCur[UM]s(), and everything related to reading the CPU
 >   cycle counter directly.  For one, it can't work correctly on
 >   machines that can change clock frequency on the fly 

 Yeep it's for fixed frequency. If it can be done for variable frequency
 w/o to much pain it's fine. Haven't even thought this thought.

 > - Fix up handling of inter-packet gap.  There was some code for
 >   enforcing a certain IPG, but the actual (CPU) cost of the sending
 >   of the packet was not substracted from that, so the effective IPG
 >   ended up being IPG+random_overhead.  This now works somewhat better

 Currently ipg is just a delay to hard_xmit and left to tester to tune.
 

 > - When ipg is set close to the HW limit, behavior becomes a bit wonky.
 >   On my EPIA board I can generate ~110kpps when I set ipg=0, but when I
 >   set ipg=10000 (which would give 100kpps), I only get ~85kps.
 > - We should rename 'ipg' to something different since in our case it
 >   never was and never will be the same as what the ethernet folks mean
 >   with it.
 > 
 > Comments welcome.

 Let me play with it. Hopefully in the beginning of the week.

                                                --ro

<Prev in Thread] Current Thread [Next in Thread>