Skip to contentSkip to conversation

net driver updates

NET Jeff Garzik 3 participants 6 messages Apr 6, 2004 – Apr 14, 2004

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

With upstream 2.6.x having been frozen for a while (and will be until end of week or so), a bunch of net driver updates have accumulated.

Even though the shortlog output is attached, here's an even shorter summary:
* acenic converted to PCI API (yay!). Please test.
* new 10gige driver, s2io
* Francois work on r8169, epic100, sis190: PCI DMA, NAPI, other minor fixes and cleanups
* 8139cp, pcnet32 updates
* other minor stuff

BK repository:

	http://gkernel.bkbits.net/netdev-2.6

Patch:
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.5-netdev2.patch.bz2

Andrew Morton:
o s2io.h: gcc-3.5 build fix

Christoph Hellwig:
o convert acenic to pci_driver API
o kill acient compat cruft from acenic

Daniel Ritz:
o netdev_priv for xirc2ps_cs, nmclan_cs

Domen Puncer:
o lmc header file not needed

Don Fry:
o pcnet32 add led blink capability
o pcnet32 correct name display
o pcnet32 all printk under netif_msg
o pcnet32.c add support for 79C976

Fran�ois Romieu:
o [netdrvr r8169] TX irq handler looping fix
o [netdrvr r8169] DAC changes
o [netdrvr r8169] Barrier against compiler optimization
o [netdrvr r8169] ethtool driver info
o [netdrvr r8169] DMA api resync
o [netdrvr sis190] more RX path work
o [netdrvr sis190] don't use one huge buffer for all RX skb's
o [netdrvr sis190] add dirty_rx to private structure
o [netdrvr sis190] separate out RX skb alloc, fill
o [netdrvr sis190] add helpers
o [netdrvr sis190] sis190_open() fixes/updates
o [netdrvr sis190] add pci-disable-device
o [netdrvr sis190] fix endianness issues
o [netdrvr epic100] napi fixes
o [netdrvr epic100] napi 3/3 - transmit path
o [netdrvr epic100] napi 2/3 - receive path
o [netdrvr epic100] napi 1/3 - just shuffle some code around
o [netdrvr epic100] minor cleanups
o [netdrvr r8169] Rx wrap bug
o [netdrvr r8169] fix TX race
o [netdrvr r8169] fix phy initialization loop init
o [netdrvr r8169] fix rx counter masking bug
o [netdrvr r8169] fix oops by removing __devinitdata marker
o 2.6.1-rc1-mm1 - typo of death in the r8169 driver
o [netdrvr r8169] Stats fix (Fernando Alencar Marótica <[email protected]>)
o [netdrvr r8169] Endianness update (original idea from Alexandra N. Kossovsky)
o [netdrvr r8169] fix RX
o [netdrvr r8169] Suspend/resume code (Fernando Alencar Marótica)
o [netdrvr r8169] Modification of the interrupt mask (RealTek)
o [netdrvr r8169] Driver forgot to update the transmitted bytes counter
o [netdrvr r8169] Merge of changes from Realtek
o [netdrvr r8169] Merge of timer related changes from Realtek
o [netdrvr r8169] Merge of changes done by Realtek to rtl8169_init_one()
o [netdrvr r8169] Add {mac/phy}_version
o [netdrvr r8169] Rx copybreak for small packets
o [netdrvr r8169] Conversion of Tx data buffers to PCI DMA
o [netdrvr r8169] rtl8169_start_xmit fixes
o [netdrvr r8169] Conversion of Rx data buffers to PCI DMA
o [netdrvr r8169] Conversion of Rx/Tx descriptors to consistent DMA

Hirofumi Ogawa:
o 8139too: more useful debug info for tx_timeout

Jeff Garzik:
o [netdrvr natsemi] correct DP83816 IntrHoldoff register offset
o [netdrvr 8139cp] better dev->close() handling, and misc related stuff
o [netdrvr 8139cp] complete 64-bit DMA (PCI DAC) support
o [netdrvr 8139cp] use netdev_priv()
o [netdrvr 8139cp] minor cleanups
o [NET] define HAVE_NETDEV_PRIV back-compat hook
o [netdrvr 8139cp] locking cleanups
o [netdrvr s2io] NAPI build fixes
o [netdrvr 8139cp] rearrange priv struct, add cacheline-align markers
o [net/fc iph5526] s/rx_dropped/tx_dropped/ in TX routines
o [netdrvr s2io] correct an incorrect cleanup I made
o [netdrvr] Add S2IO 10gige network driver
o Remove unused compatibility-defines include wan/lmc/lmc_ver.h
o Manually merge with upstream

Jeff Muizelaar:
o tc35815 cleanup

Leana Ogasawara:
o dgrs: add missing iounmaps

Luiz Fernando N. Capitulino:
o com20020-isa.c warning fix

Pavel Machek:
o Support newer revisions of broadcoms in b44.c

Randy Dunlap:
o remove magic '31' for netdev priv. alignment

Scott Feldman:
o Update MAINTAINERS with new e100/e1000/ixgb maintainers

#1 lore raw
Quoted 1 line · Jeff Garzik

* Francois work on r8169, epic100, sis190: PCI DMA, NAPI, other minor fixes and cleanups

r8169 seems to work though it is not even a tad bit faster than plain 2.6.5.

Those cards are really driving me nuts. Between two r8169 cards, one on Athlon with kernel 2.4.24, one on Athlon with 2.6.5 or 2.4.24, I get 90Mbit/s in one direction and 39Mbit/s in the other using iperf and TCP. With iperf and UDP they deliver 100Mbit/s resp. 230Mbit/s depending on the direction. Crosschecking with my PowerBook (OS X) shows that I can get 844Mbit/s (UDP) or 572Mbit/s (TCP) to one host and 844Mbit/s (UDP) but only 88Mbit/s (TCP) to the other.

The environment is switched and changing cables and/or ports doesn't improve the results.

Ideas? (Yeah, I'll get Intel NICs RSN...)

Servus,
Daniel

#2 lore raw
Quoted 7 lines · Daniel Egger
Quoted 1 line · Jeff Garzik

* Francois work on r8169, epic100, sis190: PCI DMA, NAPI, other minor fixes and cleanups

r8169 seems to work though it is not even a tad bit faster than plain 2.6.5.

Francois is still trying to fix all the vendor-created bugs, so performance is a secondary consideration.

RTL8169 is a nice chipset, though. Robert Ollsson had some nice pktgen numbers for it, IIRC.

Quoted 8 lines

Those cards are really driving me nuts. Between two r8169 cards, one on Athlon with kernel 2.4.24, one on Athlon with 2.6.5 or 2.4.24, I get 90Mbit/s in one direction and 39Mbit/s in the other using iperf and TCP. With iperf and UDP they deliver 100Mbit/s resp. 230Mbit/s depending on the direction. Crosschecking with my PowerBook (OS X) shows that I can get 844Mbit/s (UDP) or 572Mbit/s (TCP) to one host and 844Mbit/s (UDP) but only 88Mbit/s (TCP) to the other.

Quoted 4 lines

The environment is switched and changing cables and/or ports doesn't improve the results.

Ideas? (Yeah, I'll get Intel NICs RSN...)

Yeah -- I plan to kill r8169, and use 8139cp.c to drive it instead :)

Jeff

#3 lore raw

Jeff Garzik <[email protected]> :
[...]

Quoted 2 lines

Francois is still trying to fix all the vendor-created bugs, so performance is a secondary consideration.

With due respect to Realtek and others, some pesky bugs in the driver were really (c) by me.

The issues related to 64 bit host and/or link recovery seem to be gone.

If people experience issues with the r8169 driver in -mm/-netdev whereas the vanilla driver works fine, I am interested to hear from them. Preferably now.

--
Ueimor

#4 lore raw
In reply to Jeff Garzik
Quoted 1 line · Jeff Garzik

RTL8169 is a nice chipset, though. Robert Ollsson had some nice pktgen numbers for it, IIRC.

You gotta be kidding. I've not seen a single OS where this cheapass chipset was fast. It's always the last in line but maybe that's just because Realtek wrote the drivers themselves. :)

3Com/Marvell and Broadcom are much better though and I intend to try Intel, they are said to be the best.

Servus,
Daniel