[735] in linux-net channel archive
Re: How about a lance driver that receives directly into skbs?
daemon@ATHENA.MIT.EDU (Donald Becker)
Thu Jul 20 02:38:27 1995
Date: Wed, 19 Jul 95 15:07:50 EDT
From: becker@cesdis1.gsfc.nasa.gov (Donald Becker)
To: linux-net@vger.rutgers.edu
Cc: ftom@netcom.com
>I was wondering what anybody thinks about modifying the lance driver
>to receive directly into skbs, much like it currently transmits
>directly out of skbs. The AMD79C960/965 driver I wrote for NeXTSTEP
>does something like this. This could be a win because
>eth_copy_and_sum() is still 2.5 times slower than just calculating
>a checksum in place on my 486DX2/66.
The problem is knowing a priori the size of the incoming packet.
The driver could always preallocate skbuffs for maximum-sized packets, but
that would very wasteful. Ethernet traffic is known to be bimodally
distributed -- most packets are either near minimum or maximum size. At
typical sites the small packets far outnumber large packets.
>Obvious problems are the fact that some of the cards supported by the
>driver can only access the first 16MB of memory, but the driver could
>be modified to run chips in 32-bit mode (older chips would just lose).
I already have a 32 bit addressing mode driver. I never released it because
the performance improvement over the current 24 bit mode isn't significant.
Admittedly, this comparison was made using the current structure.
[[ Others have asked about the performance improvement of the "32 bit mode",
assuming it was a 16 vs. 32 bit issue. Data transfers in both modes take
place at the natural bus width with the proper alignment. The only
difference is that the 32 bit addressing mode available on the VLB and PCI
chips can directly access buffers higher than 16M.
[[ The disadvantage is that the layout of the buffer descriptors changes so
much that it wouldn't be efficient to share code in one driver. Anyone
that thinks "no big deal, it's just one more driver, why didn't you
release it?" hasn't actually had to maintain and test a set of device
drivers!]]
Donald Becker becker@cesdis.gsfc.nasa.gov
USRA Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/pub/people/becker/whoiam.html
