Re: 2.6.7 tulip performance (with NAPI)

[Ben Greear <greearb@candelatech.com>]

Robert Olsson wrote:
> Ben Greear writes:
> 
>  > 
>  > int pg_notify_queue_woken(struct net_device* dev) {
>  > 	struct pktgen_interface_info* info = dev->nqw_data;
>  > 	if (info && info->pg_thread->sleeping) {
>  > 		if (getRelativeCurNs() > (info->next_tx_ns - 1000)) {
>  > 			/* See if we should wake up the thread, wake
>  > 			 * slightly early (1000 ns)
>  > 			 */
>  > 			info->pg_thread->sleeping = 0;
>  > 			wake_up_interruptible(&(info->pg_thread->queue));
>  > 		}
>  > 	}
>  > 	return 0;
>  > }
> 
> 
>  Interesting... I got requests for higher performance in flow/DoS testing
>  to be really useful. Probably only preallocation will help here.
> 
>  To be really aggressive we could hack the driver TX handling so at TX 
>  interrupt also refills/refresh the ring but it's not a general solution. 
>  I guess you can use an existing qdisc via dev_queue_xmit() or something 
>  to save CPU in your case.
>  
>  I was sending wire rate from 10 GIGE NIC's from a DUAL XEON w. HT

You must have several PCI-X busses on that system?  From what I can tell,
my dual-xeon system (2.8Ghz, X5DPA-GG motherboard) just can't handle the
PCI bandwidth.  I still have processing power it appears, and I see lots
of hard-start-xmit errors out of the pro/1000 NICs, so I assume I am
able to drive them as hard as they can go...  It may be that receiving
the pkts, as I am doing, also decreases transmit in more than a linear fashion.

One thing I forgot to mention earlier:  I set the pktgen thread to real-time
scheduling with a user-space app.  This helps make sure it wakes up promptly.

>  I'm interested if anyone has done any pktgen performance tests with
>  w. S2IO or other 10G card we need to upgrade the lab equipment. 
>  Both 64 byte pkts and MTU sized pkts is interesting.  Anyone?

Not I, but would be interested as well!

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com