[NET] net driver updates

[NET] net driver updates

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]


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

[-- Attachment #2: changelog.txt --]
[-- Type: text/plain, Size: 3600 bytes --]


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 <famarost@unimep.br>)
  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

Re: [NET] net driver updates

[Daniel Egger]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

On 06.04.2004, at 17:30, Jeff Garzik wrote:

> * 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 478 bytes --]

Re: [NET] net driver updates

[Jeff Garzik]

Daniel Egger wrote:
> On 06.04.2004, at 17:30, Jeff Garzik wrote:
> 
>> * 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.


> 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...)

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

	Jeff

Re: [NET] net driver updates

[Francois Romieu]

Jeff Garzik <jgarzik@pobox.com> :
[...]
> 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

Re: [NET] net driver updates

[Daniel Egger]

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

On 13.04.2004, at 20:31, Jeff Garzik wrote:

> 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 478 bytes --]

Re: [NET] net driver updates

[Francois Romieu]

Daniel Egger <degger@fhm.edu> :
> On 13.04.2004, at 20:31, Jeff Garzik wrote:
> 
> > 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. :)

http://oss.sgi.com/projects/netdev/archive/2003-11/msg00399.html

Coming soon :o)

--
Ueimor