[737] in linux-net channel archive
Re: How about a lance driver that receives directly into skbs?
daemon@ATHENA.MIT.EDU (Alan Cox)
Thu Jul 20 13:26:22 1995
From: iialan@iifeak.swan.ac.uk (Alan Cox)
To: becker@cesdis1.gsfc.nasa.gov (Donald Becker)
Date: Thu, 20 Jul 1995 09:08:24 +0100 (BST)
Cc: linux-net@vger.rutgers.edu, ftom@netcom.com
In-Reply-To: <9507191907.AA03665@cesdis.gsfc.nasa.gov> from "Donald Becker" at Jul 19, 95 03:07:50 pm
> >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.
eth_copy_and_sum() could be faster - I've not applied (read lost) Tom's
patches somewhere.
> 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.
Small packets have no copy cost , large ones have a big cost. Keeping a
full sized buffer always handy would be no major cost and might be a
performance win. Also if it helps its trivial to put memory loanouts into
1.3.x buffering (allocate an sk_buff but point head/data/tail/end into the
loanout). Tracking its freeing is a minor extension.
Would that help ?
Alan
