Skip to contentSkip to conversation

8169 driver with NetGear GA511 card.

PATCH New Ben Greear 3 participants 9 messages Oct 27, 2004 – Oct 28, 2004

Subsystems (2)
lore
Share & tools
lore

Ben Greear

author
#0 lore raw

I got one of the new GigE cardbus nics today, and it just started working when I put it in (uses 8169 chipset evidently). How refreshing!

I tried stressing it, and it can handle about 30Mbps bi-directional (1514 byte pkts). I was hoping for better...but not too bad.

A bit later, my keyboard just stopped working. The scratch pad and USB mouse continued to work. System wouldn't shut down all the way either...forced fsck, system is back online.

The keyboard hang is reproducible...seems to happen as soon as I insert the NIC.

Kernel is 2.6.9 + my networking patches, compiled for pentium-M
NAPI for 8169 is enabled.

hardware is nx5000 laptop

My thanks to the 8169 driver writer(s). I will continue to debug this, and will be happy to try any suggestions for improving performance and/or stability of this NIC.

Take it easy,
Ben

Signature · 2 lines
Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com
author
#1 lore raw
Quoted 4 lines · Ben Greear

Kernel is 2.6.9 + my networking patches, compiled for pentium-M
NAPI for 8169 is enabled.

hardware is nx5000 laptop

I recompiled w/out NAPI and no more problems, though performance is horrible (about 5Mbps bi-directional).

If the developer/maintainer could use one of these cardbus NICs, I'm willing to donate one to help further development and stability.

Thanks,
Ben

Signature · 2 lines
Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com
#2 lore raw
In reply to Ben Greear

Ben Greear <[email protected]> :
[...]

Quoted 2 lines

I tried stressing it, and it can handle about 30Mbps bi-directional (1514 byte pkts). I was hoping for better...but not too bad.

There is a direction for which a 2x factor has been reported. It does not look like a completely dysfunctional setup.

[...]

Quoted 6 lines

Kernel is 2.6.9 + my networking patches, compiled for pentium-M
NAPI for 8169 is enabled.

hardware is nx5000 laptop

My thanks to the 8169 driver writer(s). I will continue to debug

Many people help.

Quoted 2 lines

this, and will be happy to try any suggestions for improving performance and/or stability of this NIC.

The r8169 in -mm and in -netdev includes some extra buzzword-compliant features (TX csum/SG and TSO mainly). The changes are isolated in a single patch against 2.6.9 available at:
http://www.fr.zoreil.com/people/francois/misc/20041020-2.6.9-r8169.c-test.patch

I will not claim it is as stable as vanilla 2.6.9 should be.

The frequency of requests for jumbo frames went higher lately ("Realtek driver does it"). There is some code I need to test before it is pushed to -mm.

Btw:
[...]

Quoted 2 lines

I recompiled w/out NAPI and no more problems, though performance is horrible (about 5Mbps bi-directional).

Please send the usuals 'lspci -vx' + /proc/interrupts contents during activity + complete dmesg + short description of the generated traffic. I will hardly dissect it before the week end but there is a problem. :o(

Quoted 2 lines

If the developer/maintainer could use one of these cardbus NICs, I'm willing to donate one to help further development and stability.

I work with the plain PCI version of the GA 511 but I can use a laptop for testing. Please contact me offline if you can send an adapter and accept euro.

--
Ueimor

author
#3 lore raw
Quoted 6 lines · Francois Romieu

The r8169 in -mm and in -netdev includes some extra buzzword-compliant features (TX csum/SG and TSO mainly). The changes are isolated in a single patch against 2.6.9 available at:
http://www.fr.zoreil.com/people/francois/misc/20041020-2.6.9-r8169.c-test.patch

I will not claim it is as stable as vanilla 2.6.9 should be.

I'm running tests at the ethernet frame (skb) level, so I would not expect the IP offload to help much.

Do you have any performance numbers for your 8169 cards for me to compare against?

Quoted 3 lines

Please send the usuals 'lspci -vx' + /proc/interrupts contents during activity + complete dmesg + short description of the generated traffic. I will hardly dissect it before the week end but there is a problem. :o(

I'll get this in a bit, as I have locked up the keyboard again. This time, I was still using the non-NAPI code which had run over-night at around 5Mbps...

I tried a different network setup, and noticed that the 8169 was only negotiating 10bt/HD. That would explain the poor performance numbers. The NIC was connected to a BCM5705M when I noticed this, though it had been connected to an e1000 earlier.

I tried forcing both NICs to 100bt/FD. The BCM would force to that speed, but the 8169 would only force to 100bt/HD. While attempting to change them back to auto-negotiate, I noticed that the keyboard had quit working...

With regard to the BCM, it is interesting in that ethtool reports that it supports only up to 100bt/FD, but it advertises 1000bt/FD.

The wierd advertise and negotiation stuff could be at least partly my fault as I have a program that manipulates these settings from default. I will continue to play with this later this evening...

Ben

Signature · 2 lines
Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com
#4 lore raw

Ben Greear <[email protected]> :
[...]

Quoted 5 lines

I'm running tests at the ethernet frame (skb) level, so I would not expect the IP offload to help much.

Do you have any performance numbers for your 8169 cards for me to compare against?

Gross numbers:
- with a receiving amd64, nttcp should saturate the GigaE link;
- halved bandwidth for Tx on the same setup. Untested since changes in -mm;
- 10% cpu on a 100bt link;
- TSO saves 5~7% of the cpu when it can be used.

saturated
- old host system (PII class): on 100bt, napi chews 4x10kpps (icmp) without significant load.

[...]

Quoted 6 lines

I'll get this in a bit, as I have locked up the keyboard again. This time, I was still using the non-NAPI code which had run over-night at around 5Mbps...

I tried a different network setup, and noticed that the 8169 was only negotiating 10bt/HD. That would explain the poor performance numbers.

Call me dense but... Are the 5Mbps below in the same unit as the 30Mbps in your previous message (are they bytes or bits) ? If yes something is badly broken.

--
Ueimor

author
#5 lore raw
Quoted 10 lines · Francois Romieu

Ben Greear <[email protected]> :
[...]

Quoted 5 lines

I'm running tests at the ethernet frame (skb) level, so I would not expect the IP offload to help much.

Do you have any performance numbers for your 8169 cards for me to compare against?

Quoted 5 lines

Gross numbers:
- with a receiving amd64, nttcp should saturate the GigaE link;
- halved bandwidth for Tx on the same setup. Untested since changes in -mm;
- 10% cpu on a 100bt link;
- TSO saves 5~7% of the cpu when it can be used.

Cool, I am glad to know the chipset can handle it at least...

Quoted 9 lines
Quoted 5 lines

I'll get this in a bit, as I have locked up the keyboard again. This time, I was still using the non-NAPI code which had run over-night at around 5Mbps...

I tried a different network setup, and noticed that the 8169 was only negotiating 10bt/HD. That would explain the poor performance numbers.

Call me dense but... Are the 5Mbps below in the same unit as the 30Mbps in your previous message (are they bytes or bits) ? If yes something is badly broken.

Yes, but I think now the problem is that it was stuck at 10bt/HD for whatever reason. There seems to be a way to lock the keyboard by trying to make the NIC change it's negotiate settings. I am going to try to track down exactly how this can be reproduced with minimum number of steps...

Thanks,
Ben

Signature · 2 lines
Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com
#6 lore raw

PATCH 1/1 r8169 tx checksuming on by default

In reply to Francois Romieu

The tx checksumming and scatter-gather in r8169 runs well. Below is a trivial patch to turn them on by default.

r8169.c 2004-10-28 15:21:03.000000000 -0500 renamed from r8169.c.orig 2004-10-28 15:02:07.000000000 -0500 +2 -0
@@ -1337,6 +1337,8 @@ rtl8169_init_one(struct pci_dev *pdev, c
        dev->poll_controller = rtl8169_netpoll;
 #endif
 
+       dev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
+
        tp->intr_mask = 0xffff;
        tp->pci_dev = pdev;
        tp->mmio_addr = ioaddr;
Signature · 2 lines
Jon Mason
[email protected]
#7 lore raw
In reply to Ben Greear
Quoted 3 lines · Ben Greear

A bit later, my keyboard just stopped working. The scratch pad and USB mouse continued to work. System wouldn't shut down all the way either...forced fsck, system is back online.

I was seeing similar behavior with high workloads and TSO. Can you confirm that you are running with TSO on?

Signature · 2 lines
Jon Mason
[email protected]
author
#8 lore raw
Quoted 8 lines · Jon Mason
Quoted 3 lines · Ben Greear

A bit later, my keyboard just stopped working. The scratch pad and USB mouse continued to work. System wouldn't shut down all the way either...forced fsck, system is back online.

I was seeing similar behavior with high workloads and TSO. Can you confirm that you are running with TSO on?

I'll have to check, but I do know that the traffic I was sending was at the ethernet frame level and it was UDP packets.

Signature · 2 lines
Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com