Thanks for you help guys! I broke NAPI (don't hate me) and then went on vacation, so I apologize for not responding sooner. I like what you've come up with here, so I'll turn the patch around for Je
Hello! Honestly not too much thinking... well we can always argue by having Rx last we get more packets per poll. Yes we should test the other way around. Also still some concern by having the watchd
e1000_intr feels better to me in keeping the clean-up work separate from managing link status change (hopefully an infrequent event :). Do you see any problems? Ya, that read hurts, which was part o
It works. Reducing PCI accessess gives a measurable improvement. I'll post plots later today. -- Jason Lunz Reflex Security lunz@xxxxxxxxxxxxxxxxxx http://www.reflexsecurity.com/
Well I was afraid that this would not be run at very heavy loads due to interrupt disabling but I forgot: e1000_watchdog(unsigned long data) { /* Cause software interrupt to ensure rx ring is cleaned
TX frees skbs, RX allocates skbs. You lessen the chance of allocation failure or "additional work" being performed by the allocator when you do it in this order. Jeff
The graphs are up now. The best driver measured so far is Robert's change to reinstate irq-disable-on-poll + reduce-pci-traffic, with XsumRX turned off. I'm currently measuring to see if it still has
Very good. Jeff has the patch for -k2 which should be equivalent to -ro2. Robert, please post your -ro3 changes - I can't find them. BTW, the things that changed from 4.4.19-k3 to 5.0.43-k2 that may
sorry, the -roX and -sfX notations are mine; i'm backporting everything to 2.4.20 for testing and most of the patches have to be tweaked one way or another, so I gave them all my own names to help ke
For review by the list... The other e100/e1000 changes are in the 2.5 nightly snapshot on kernel.org... -- Begin Message -- To: bk-commits-head@xxxxxxxxxxxxxxx Delivered-to: garzik@gtf.org Delivered-
It's clean but I have some concerns... I think this will add interrupts when resources are fully utilized. In other words a decrease in top performance. I say "think" because I have no numbers. At GI
Thanks for the feedback. It's a twist on the previous driver where we disabled/enabled interrupts each time we went in/out of polling. Trying to avoid those extra PCI writes. My experience is that y
True. Making interrupt delay larger will collect more packets on RX-ring and have the two PCI-writes to disable/enables irq to be shared by many packets. So I fear that interrupts are now added to th
Hello! Here is a hi-perf routing/DoS to start with... 10 Million pkts injected at high speed into eth2 and forwarded to eth3. Rx and Tx buffers are 256 and HW_FLOW is disabled and RxIntDelay=1. Which
I've seen pretty much the same thing. I plotted throughput vs. offered load for e1000 4.4.12-k1, 4.4.19-k3, and 5.0.43-k1 (all backported to 2.4.20). A summary with graphs is at: http://gtf.org/lunz/
We have a winner! I called the driver with your patch 5.0.43-k1-ro1. I also removed all the cyclesoak lines; all they really show is that throughput is really sensitive to how much CPU time ksoftirqd
Excellent! We have a flat performance curve at ~350 kpps at any load and packet size again. Of course this can be improved further. I think Intel still did the hard work but left the "fine" tuning an
A better approximation I think but probably not the last... Cheers. --ro -- linux/drivers/net/e1000/e1000_main.c.orig 2003-03-27 14:38:02.000000000 +0100 +++ linux/drivers/net/e1000/e1000_main.c 200