On 2/22/06, Simon Kirby <[EMAIL PROTECTED]> wrote: > Of course, now it doesn't send as fast. Hrmph. :) On this older Xeon > 2.4 Ghz w/533 FSB and e1000 & tg3 @ PCI-X 133 Mhz 64 bit, SMP kernel, > single pktgen thread, I'm only seeing: > > clone_skb=0, 802.1Q tagging, 60 byte: > e1000: 558526pps 268Mb/sec (268092480bps) errors: 0 > tg3: 621260pps 298Mb/sec (298204800bps) errors: 0 > > clone_skb=0, no 802.1Q, 60 byte: > e1000: 664558pps 318Mb/sec (318987840bps) errors: 0 > tg3: 772650pps 370Mb/sec (370872000bps) errors: 0 > > clone_skb=16384, no 802.1Q, 60 byte: > e1000: 684206pps 328Mb/sec (328418880bps) errors: 0 > tg3: 1069830pps 513Mb/sec (513518400bps) errors: 0 > > I tried on an Opteron 140 box and it was faster for both cards, but not > by much. oprofile showed a lot of do_getttimeofday, so I hacked a bunch > of calls out of pktgen -- I noticed the CPU time shifted around but the > throughput was still the same as before, as if it's card or bus limited. > > Why is it so difficult to actually get 1 Gbps of small packets? I also > tried changing ring buffer sizes, txqueuelen, interrupt coalescing > settings, etc... all I was able to do was make it slower or very > slightly faster.
Its difficult because you have *loads* of transactions going over the bus. Linux's single transmit packet at a time methodology also exacerbates this, as we're unable to coalesce transmit tail (TDT) writes to the bus and are probably interrupting the previous DMA *a lot* (see thread below) You'll probably be able to get a little better throughput by switching to a UP kernel, but from my experience you're getting pretty close to the max for pci-x e1000 adapters. There are some previous messages about this like: http://oss.sgi.com/projects/netdev/archive/2004-12/msg00017.html beware the hardware bug when enabling TXDMAC! Jesse - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
