[745] in linux-net channel archive
Re: How about a lance driver that receives directly into skbs?
daemon@ATHENA.MIT.EDU (Tom May)
Fri Jul 21 07:29:24 1995
Date: Thu, 20 Jul 1995 15:37:00 -0700
From: ftom@netcom.com (Tom May)
To: becker@cesdis1.gsfc.nasa.gov
CC: iialan@iifeak.swan.ac.uk, linux-net@vger.rutgers.edu
Donald Becker:
>>> The problem is knowing a priori the size of the incoming packet.
>>> The driver could always preallocate skbuffs for maximum-sized packets, but
Alan Cox responds:
>>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.
Donald Becker again:
>Keep in mind that it's not just keeping one full-sized skbuff around, it's
>keeping a whole Rx ring of full-sized skbuffs around.
The driver is currently statically allocating 16 buffers of 1544 bytes
each, which is a substantial amount of memory. Then the data gets
copied from there to an sk_buff and takes up more memory. The large
vs. small packets muddies the issues a bit; perhaps what Donald wrote:
> 1. Always keeping max-size skbuffs for the device's Rx buffer ring, but
> allocating a smaller skbuff and copying the data if we get a "small"
> packet.
is a decent compromise since the copy/csum is swamped by other
overhead for small packets. It also has the advantage of quickly
returning the skbuff to the rx ring (assuming the "loanout" stuff
below is implemented) which is important for back-to-back small packet
reception. Unfortunately, the divison between small and large is a
system-dependent tuning thing.
Alan:
>>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.
Donald:
>You mean "loanout" in the sense of the recent networking literature, where
>the device driver "owns" the memory rather than the kernel, right? The
>current LANCE Rx structure would lend itself well to that. A danger is that
>the interaction between the layers is more complex, and just a few misplaced
>or delayed-free buffers would cripple the device driver. Alan, do you think
>it's safe enough?
The non-Linux AMD79C960/965 driver I did owned the buffers, and filled
in the rx ring if necessary as the buffers were freed. In addition,
all the buffers were preallocated in the low 16MB of memory for the
ISA version. Determining how many buffers to allocate was trial and
error (queueing theorists may disagree :-)
Tom.
