[741] in linux-net channel archive
Re: How about a lance driver that receives directly into skbs?
daemon@ATHENA.MIT.EDU (Donald Becker)
Fri Jul 21 01:56:27 1995
Date: Thu, 20 Jul 95 11:08:56 EDT
From: becker@cesdis1.gsfc.nasa.gov (Donald Becker)
To: ftom@netcom.com, iialan@iifeak.swan.ac.uk, linux-net@vger.rutgers.edu
Donald Becker responds
>> 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.
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. For most boards
those skbuffs must reside in low memory below 16M.
Perhaps you mean:
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.
2. Having the updated driver work only with the VLB and PCI boards w/ 32
bit addressing to avoid the <16M skbuff location problems.
3. Perhaps using fewer Rx buffers to reduce the size of the "idle" buffer
pool owned by the device.
#2 is probably necessary, and it provides a substantial reason to release a
32-bit-addressing version of the driver.
#3 is probably a bad idea -- the current driver keeps a 16 entry Rx ring.
Dropping that to 4 or 8 entries would run the risk of dropping back-to-back
minimum-sized packets. For a reference the original 3c509, notorious for
having a small Rx buffer, could handle about 30 back-to-back minimum-sized
packets before droppping packets. (Yes, I know that's a unfair comparison.)
Anyway, this sounds like a win, and it's straight-forward to do. I'll
probably try it out with the Tulip driver (very similar to the LANCE driver)
today.
>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.
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?
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
