[ I CC'd Matt Thomas on this, cuz he might have a suggestion or two
  regarding sneaky mbuf tricks and eliminating copies, etc.]

On Mon, 26 Aug 1996 13:34:23 +0930 
 Ian Dall <Ian.Dall@dsto.defence.gov.au> wrote:

 > It seems the only way is to poll it with scsi "read" commands. These would
 > presumably be scheduled using timeout(). It is a bit of a wart but it still
 > beats a serial port!

Hmm ... perhaps ... "I guess I could always look at the etherd code 
before I comment further."  :-)

Where is it available, again?

 > Given the pseudo-dma aspect of pc532 scsi-io, it would be possible to
 > read/write directly into the mbuf chain. However, in practice that
 > is probably more complication than it is worth seeing as it would need
 > changes to the device driver level.

You can't make any assumptions about the underlying SCSI controller 
driver.  I.e. I may want to use this device on an alpha, or on a sparc, 
etc.  Now, it may be possible that you can optimize out the copy...

For example, it may be the case that the device can tell you how large 
the packet is before you go off and read it (rather than just assuming 
ETHERMTU bytes) ... in this case, you may be able to allocate a cluster 
mbuf and read the data directly into it (Matt?  Can you suggest any other 
tricks here?)

It seems really unlikely to me that you can eliminate the copy on 
transmit, unless, of course, the packet fits entirely into one mbuf 
(which may or may not be all that common; you'd have to gather some 
statistics on that...)

Ciao.

 -- save the ancient forests - http://www.bayarea.net/~thorpej/forest/ -- 
Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939