An old discussion at
http://lkml.indiana.edu/hypermail/linux/net/0810.1/0009.html
says
I said that without HW flow seperation support, you can only expect N
cpus to be busy where N is the number of NICs you have.
What is HW flow seperation support? Can someone name a few adaptors
supporting HW
On Mon, Jun 1, 2009 at 9:21 PM, Brandeburg, Jesse
jesse.brandeb...@intel.com wrote:
Peter, you're correct, however the tx queue interface is protected by locks
(qdisc lock, netdev lock) in the stack. And newer kernel versions of e1000
don't even have the tx_ring lock any more (in the
I am using 7.3.20-k2-NAPI version of e1000 driver on Linux 2.6.21
On a moderate traffic rx_no_buffer_count remains constant, but on
heavy traffic rx_no_buffer_count keeps increasing.
rx_no_buffer_count: 4094038
rx_no_buffer_count: 4094038
rx_no_buffer_count: 4094038
My original speculations were wrong: it goes wrong with 32-bit as well
as 64-bit kernels. The key is that it only ever goes wrong with the
in-tree driver. When I compiled the faulty kernels (32- and 64-bit), I
forgot to copy the out-of-tree driver into place. Use the out-of-tree
driver, and
On Tue, Jun 2, 2009 at 2:00 PM, Waskiewicz Jr, Peter P
peter.p.waskiewicz...@intel.com wrote:
http://e1000.sf.net
Cheers,
PJ Waskiewicz
peter.p.waskiewicz...@intel.com
-Original Message-
From: Lal [mailto:learner.ker...@gmail.com]
Sent: Tuesday, June 02, 2009 12:05 AM
To: e1000
In e1000_clean function in drivers/net/e1000_main.c file, tx_ring[0]
is protected by spin lock to prevent from being cleaned by multiple
cpus simultaneously, but rx_ring[0] is not.
Why rx_ring[0] is not protected from multiple cpus ?
Thanks
-Lal
