[378] in linux-scsi channel archive
Re: Reading more than buffersize
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Sat Jul 15 19:23:42 1995
Date: Sat, 15 Jul 95 14:31 EDT
From: eric@aib.com (Eric Youngdale)
To: drew@poohsticks.org, mucci@cs.utk.edu
CC: linux-scsi@vger.rutgers.edu
>> Instead of doing things to a buffer and then copying to memory, it should
>> lock the relevant pages of user memory in core (there are mlock patches
>> floating arround somewhere for this), and do however many SCSI commands are
>> necessary (based on the number of scatter/gather segments supported by the
>> low level driver being used) to transfer data to those locations.
>
>Yes! The 0-copy approach! Most of the newer OSs are providing such things
>as 0 copy device reads and 0 copy network stacks where possible. (I think
>HP is pushing the envelope on this approach.) We need a generic interface
>to do DMA direct to user space...
This would be an interesting approach. The thing that would
be tricky about it is that we need some generic interface to lookup
the physical address based upon a virtual address in the user's space,
plus we have to be aware that we could (and probably will) have a new
physical page at each page boundary. Also, we have to use bounce buffers
if the low-level driver does not support DMA to addresses > 16Mb
(see the disk code for how to do this).
We would also need some way of signaling whether it is
possible/wise to split up transfers into smaller requests, or whether
we should do the whole thing as one request. Note that some host
adapters (i.e. 1542) have a limit to the size of the scatter-gather table,
so you are automatically limited to 16*4Kb=64Kb transfers per command
(since we assume that adjacent pages in VM are not adjacent in PM.
Do we have any volunteers to take on this little project? I
can provide suggestions and code review, but I am a bit busy at the
moment with other things so I don't want to take this on now. It
would be pretty easy to prototype and debug most of the code in user space.
Here is an interesting thought - we could provide a generic
character device interface for disks/cdroms. Hint: the corresponding
character device major numbers 8 and 11 are currently unused :-).
Just think of the I/O throughput we could get. While this would be a
nice hack, it would probably be preferable to do this as a sort of
generic interface to all scsi devices, and have hooks to get to this
from the disk/cdrom drivers. The only reason you might require a tie-in
between the block disk driver and the character disk driver is so that
partition table information can be accessed. This needs a little more
thought before it can be implemented, but it should not be too hard.
-Eric
