Re: changes to kiobuf support in 2.4.(?)4

[Ingo Oeser]

On Thu, Aug 02, 2001 at 08:23:37AM +0000, Gerd Knorr wrote:
> >  The reason of the large allocation and to put the bh inside the kiobuf
> >  is that if we do a small allocation then we end with a zillion of
> >  allocations of the bh and freeing of the bh at every I/O!! (not even at
> >  every read/write syscall, much more frequently)
> 
> That is true for block device I/O only.  Current bttv versions are using
> kiobufs to lock down user pages for DMA.  But I don't need the bh's to
> transfer the video frames ...

This is another problem. We miss a whole layer of fast streaming
and chunking IO, which is not meant for block devices.

The most practical example would be the sg-driver, but there are
other things which require this kind of semantic:

Transmit Buffer via DMA to device (and programming it for
operations on that buffer) and possible receiving sth. back.

We need no reordering here, but would like to do the DMA directly
from user space buffers.

Examples:

   - GiMP plugin, which renders some complex algorithm on a DSP.

   - Crypto (Co-)processors, which encrypt data streams

   - Screengrabbers, which can grab a specific area.

   - (intelligent, multi) data aquisistion devices (large sensor
     arrays)

   ...

I would like to have a thing like the zero copy IO in the network
layer, but not done with NICs only, but with ANY device.

For the DSP case (which might be the most complex one) I did some
research already, but I don't like to see this work duplicated
over and over again.

I built transfer structs similar to BHs but more simply and have
a queue of that per device and allocate transfers from a slab.

The blocking and unblocking is done in the driver anyway. I only
try to do zero copy IO, if I have complete pages, which
simplifies it a "little" ;-)

Without the coalescing and reordering it's pretty simple.

What do the gurus think here?

Regards

Ingo Oeser
-- 
You mean a kill file only kills email!!!! DAMN!!!! All these years
I thought I was doing the gene pool some good...
                             --- "Clint Wolff" <[e-mail]>