Re: [Patch 2.6.22.2 ] : drivers/net/via-rhine.c: Offload checksum handling to VT6105M
[top posting because context may be missing otherwise, over a week later] Excellent analysis, Willy. Quite frankly, I am not keen on making this driver any more complex, especially if the gains are marginal at best. VIA Rhine will never be high-performance hardware, and we have too much special casing already. Patches to fix actual problems (such as the recent irq init work by Dave Jones) are much more interesting to me (and presumably to most via-rhine users). Roger On Sun, 30 Dec 2007 23:33:54 +0100, Willy Tarreau wrote: Hi Kim, On Fri, Aug 17, 2007 at 11:34:37AM -0700, K Naru wrote: From: Kim Naru ([EMAIL PROTECTED]) Added support to offload TCP/UDP/IP checksum to the VIA Technologies VT6105M chip. Firstly, let the stack know this chip is capable of doing its own checksum(IPV4 only). Secondly offload checksum to VT6105M, if necessary. Verbose Mode: #1. Define 3 bits(18,19,20) in Transmit Descriptor 1 of chip, which affect checksum processing. The prefix(TDES1) for the 3 variables is the short name for Transmit Descriptior 1. #2. In rhine_init_one(), if pci_rev = VT6105M then set NETIF_F_IP_CSUM(see skbuff.h for details). #3. In rhine_start_tx() if NETIF_F_IP_CSUM is set AND the stack requires a checksum then set either bit 19(UDP),20(TCP) AND bit 18(IP). Note : The numbered items above(i.e.#1,#2,#3) denote pseudo code. This patch was developed and tested on Imedia linux-2.6.20 under a PC-Engines Alix System board (www.pcengines.ch/alix.htm). It was tested(compilation only) on linux-2.6.22.2. The minor code change between 2.6.20 and 2.6.22 is the use of ip_hdr() in 2.26.22. In 2.6.20 : struct iphdr *ip = skb-nh.iph; In 2.6.22 : const struct iphdr *ip = ip_hdr(skb); Testing: ttcp,netperf ftp and top where used. There appears to be a small CPU utilization gain. Throughput results where more inconclusive. The data sheet used to get information is 'VT6105M Data Sheet, Revision 1.63 June21,2006'. Signed-off-by: Kim Naru ([EMAIL PROTECTED]) --- Well, I've reformated your patch so that it can be applied, and very slightly arranged it in order to save 13 bytes of code and a few CPU cycles. Also, I moved the if block before the spinlock as there is no reason for this code to be run with the lock held. I have run some performance measurements on an ALIX 3C2 motherboard with a 2.6.22-stable kernel. What I see is a reduction of CPU usage by about 20% when the network is saturated, but also a reduction of the network speed by 8%! Without the patch, I can produce a continuous traffic of about 99 Mbps with about 11% CPU (system only, 89% idle). With the patch, the traffic drops to 91 Mbps but CPU usage decreases to 9%. Now, if I reduce the MTU to exactly 1000, then the traffic increases to about 98 Mbps, but it progressively reduces when the MTU moves away from 1000. So I have run some deeper tests consisting in leaving NETIF_F_IP_CSUM unset and still asking the NIC to compute the checksums. The conclusion is very clear: as soon as *any* checksum bit is set (IP, TCP, UDP), the traffic immediately drops. I think that what happens is that the NIC is not pipelined at all and that no data is transferred while a checksum is being computed. This would also explain why reducing the MTU increases performance, since it reduces the time required to compute a checksum, reducing the off time. And the more I think about it, the more I think this is the problem, because the VT6105M has a 2kB transmit buffer, so it cannot checksum a 1.5kB frame while sending another one if it does it inside the buffer. And I'm pretty sure that the checksum is computed in the buffer and that the data is not transferred twice on the bus, because playing with PCI latency timer and other parameters does not change anything. So basically, we're there with a chip which can offload the CPU by performing the checksums itself, but it reduces performance for packets larger than 1kB (or possibly 500 bytes if there's a 1.5kB packet being transferred). The driver should be adjusted to permit the user to enable and disable this feature with ethtool. Right now, its status can only be consulted, and I'm using dd on /dev/mem and /dev/kmem to change the values on the fly. Given the fact that a 20% reduction on CPU usage which was already 10% only leaves a net gain of about 2% more CPU available, I'm not convinced that there is any advantage in enabling this feature by default with this NIC. Here's the updated patch for reference (maybe you'd want to enhance it). --- linux-2.6.22-wt3/drivers/net/via-rhine.c 2007-11-22 17:48:34 +0100 +++ linux-2.6.22-wt3.via-cksum/drivers/net/via-rhine.c2007-12-30 20:53:30 +0100 @@ -95,6 +95,8 @@ #include linux/netdevice.h #include linux/etherdevice.h #include linux/skbuff.h +#include linux/in.h
Re: network freeze with nforce-A939 integrated rhine card
On Thu, 11 May 2006 22:59:44 -0700, David Lang wrote: I haven't had time to go back and find where is started (my prior kernel was 2.6.15-rc7), but with 2.6.17-rc1/2/3/4 I've been running into a problem where when transfering large amounts of data (trying to ftp a TB where is started sounds as if it used to work at some point. In your second posting, however, you note that the problem goes back at least to 2.6.13. So are there any kernels known not to exhibit the problem you described? when I say shut down I mean that it looses link and requires powering down the box (hard power down, not just power off from the front panel), disabling the network card in the BIOS, booting (as far as lilo is enough), powering down again, enabling the card and booting again. So there are two problem areas: 1) the chip hangs itself without the driver noticing and 2) the BIOS fails to bring the chip back to life afterwards. there is no indication of trouble before the halt (it's transfering at full speed), the only think in the log is May 11 22:23:57 david kernel: eth0: link down May 11 22:24:00 david kernel: eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1 May 11 22:24:22 david kernel: eth0: link down if I don't do the disable/enable in the bios cycle and just power cycle the system the card does not initialize properly (ethtool reports autonegotiation disabled, 10Mb. will generate an 'unsupported' error if I try to enable the card) Any difference in the kernel log when booting with (or ethtooling) a comatose chip? [EMAIL PROTECTED]:~$ /sbin/lspci 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0204 00:00.1 Host bridge: VIA Technologies, Inc.: Unknown device 1204 00:00.2 Host bridge: VIA Technologies, Inc.: Unknown device 2204 00:00.3 Host bridge: VIA Technologies, Inc.: Unknown device 3204 00:00.4 Host bridge: VIA Technologies, Inc.: Unknown device 4204 00:00.7 Host bridge: VIA Technologies, Inc.: Unknown device 7204 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800 South] 00:08.0 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) 00:08.1 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) 00:0a.0 Ethernet controller: Olicom OC-2326 (rev 01) 00:0f.0 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C/VT8235 PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [K8T800 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01) Odd. This doesn't look at all like the list I'd expect from an nforce-A939. I thought Nvidia devices featured rather prominently in the device lists of nforce-based boards!? Roger - 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
Re: via_rhine modules error on 2.6.16 with mii-tool
On Thu, 13 Apr 2006 14:26:43 -0400, John W. Linville wrote: I wonder if low latency for ancient Rhine-I chips is worth the trouble. IIRC, the point was that mdelay was getting called in interrupt context and causing ugly messages to show-up in dmesg. I suppose the patch back then was to reduce latency; the ugly messages in the kernel ring buffer were _introduced_ with the patch (you shouldn't get error messages calling mdelay in interrupt context because that's what mdelay is for). Would the patch below be sufficient? Or does the whole patch need to be reverted? I'd revert the whole thing. There's no point in having the additional work_struct complexity if we end up calling mdelay anyway. Roger - 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
Re: via_rhine modules error on 2.6.16 with mii-tool
On Thu, 13 Apr 2006 11:40:18 -0700, Stephen Hemminger wrote: The right thing to do is get rid of the locking in via_rhine:netdev_ioctl and push the locking down into mdio_read, mdio_write. As I said before, a dozen other network drivers do the exact same thing -- they call generic_mii_ioctl right after grabbing the private spin lock (and only one driver calls generic_mii_ioctl without taking the lock). I am not keen on patches that make via-rhine more of a special case even if it was safe now; next thing you know generic_mii_ioctl is changed in a way that breaks the only driver that foolishly made assumptions about the side-effects of that function. If you can safely move the locking down for all network drivers, that would be a different story, of course. Roger - 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
Re: via_rhine modules error on 2.6.16 with mii-tool
On Thu, 13 Apr 2006 14:02:52 -0700, Stephen Hemminger wrote: I am not keen on patches that make via-rhine more of a special case even if it was safe now; next thing you know generic_mii_ioctl is changed in a way that breaks the only driver that foolishly made assumptions about the side-effects of that function. If you can safely move the locking down for all network drivers, that would be a different story, of course. Didn't your mother ever tell you that just because everybody else does it wrong, you don't have to. No, but she warned me not to spend time on fixing botched low latency patches. Look, it took a lot of time to make via-rhine stable. It's still got unexplained issues. I have a patch here for a bug that makes a driver reload necessary when it occurs (and the patch is sitting here because nobody's able to reproduce the problem anymore). I am lacking adequate documentation, I have little time to work on the driver, but quite a to do list. Does that sound like via-rhine would make a good guinea pig? The other drivers should be fixed as well. Phy access with irq's disabled is not good. The hardware I checked takes 100's of usecs to do one read transaction. If you want to fix this in all drivers, more power to you. It is just not high on my own priority list. I see the need for low latency, but latency issues that only happen when people fiddle with MII settings don't seem all that dramatic to me. Roger - 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
Re: via_rhine modules error on 2.6.16 with mii-tool
On Fri, 24 Mar 2006 16:49:10 +0100, Marco Berizzi wrote: Hello evebody. I get this error on linux vanilla 2.6.16 with via_rhine module loaded when I run mii-tool: That was caused by a recent change that replaced an mdelay with msleep. netdev_ioctl and friends (ethtool calls, too) are known to grab a spin lock before they do much of anything, and they hang onto it until they're done. They also call mdio_read/write, which requires millisecond delays on Rhine-I. So on Rhine-I with a 2.6.15+ kernel, the driver ends up calling msleep while holding a spin lock -- hence the stack dump. I wonder if low latency for ancient Rhine-I chips is worth the trouble. Roger - 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
