Greetings,
I've noticed two non-trivial performance drops in the E1000E driver
over time:
1) Between 0.4.1.2 and 0.5.8.2 an e1e_flush() call was added to the end of the
e1000_irq_enable() function. In my testing, I noticed roughly an 8%
performance hit as a result.
a) This is a bit of a shock that merely reading the device status
register turns out to be such an expensive operation. Any comments?
b) Why was this call added?
c) Am I likely to run into trouble by removing it?
2) Between 0.5.11.2 and 0.5.18.3 the behavior of the e1000_poll() routine
changed. Previously, rx_irqs were not enabled until there was a poll with no
work performed. Subsequently, rx_irqs were re-enabled if we didn't consume our
entire budget of work. There was a corresponding change to _kc_adapter_clean()
where we previously returned 1 if any work was done to only returning 1 if we
consumed our entire budget of work. These changes caused a a 4-5% performance
hit in my testing.
IMO it seems more intuitive to poll as long as there are packets to be
processed. The higher the percentage of packets processed due to interrupt
when the system is heavily loaded the worse it is for performance. I see that
there might be a small latency penalty by staying with polling mode longer --
but I'd rathe trade a very minor latency hit for better performance under high
load. Or am I missing something?
Any thoughts to share on that?
Thanks!
Rodger Erickson
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
E1000-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit
http://communities.intel.com/community/wired
