Messages in this thread | | | Subject | RE: [PATCH 2.6.32 2/3] net: Fix ks8851 snl transmit problem | Date | Thu, 3 Dec 2009 16:57:27 -0800 | From | "Ha, Tristram" <> |
| |
David Miller wrote: > From: "Ha, Tristram" <Tristram.Ha@Micrel.Com> > Date: Thu, 3 Dec 2009 13:17:48 -0800 > >> This fixes a transmit problem of the ks8851 snl network driver. Under heavy TCP traffic the >> device will stop transmitting. Turning off the transmit interrupt avoids this issue. A new >> workqueue was implemented to replace the functionality of the transmit interrupt processing. >> >> Signed-off-by: Tristram Ha <Tristram.Ha@micrel.com> > > Please describe why the TX interrupt facility cannot be used. > You probably have a race condition or similar, have you tried to see if there is some issue like > that? > > This workqueue is going to make performance terrible, at best.
I am a software engineer at Micrel, Inc., which developed the KSZ8851 SNL chips. This transmit problem is a hardware issue as the same problem is encountered in different drivers like WinCE. We have not pinpointed the hardware bug. I do not think there is something wrong in the driver. Turning off the transmit interrupt is just a workaround.
I know the new workqueue implementation is polling. But in my experience, interrupting the system for each packet sent likely degrades the system performance more. The workqueue is only called when the transmit buffer is empty, which happens after 3 or 4 packets are sent quickly in succession. The workqueue schedules itself again if the transmit buffer is still not available, but in practice this case never happens.
The KSZ8851 chips do not need special transmit interrupt handling routine to cleanup the registers or socket buffers. It is better to turn it off for better performance. Because the KSZ8851 SNL uses SPI, its driver has restrictions of when to call SPI host to access registers. That is why the original driver implementation uses a workqueue to check the transmit buffer during transmit interrupt handling.
| |