home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11867 < prev    next >
Encoding:
Text File  |  1992-12-22  |  2.9 KB  |  57 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!mcsun!Germany.EU.net!news.uni-bielefeld.de!rz.ruhr-uni-bochum.de!jan
  3. From: jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen)
  4. Subject: Re: question about DMA devices
  5. Message-ID: <JAN.92Dec22183354@pallas.neuroinformatik.ruhr-uni-bochum.de>
  6. Followup-To: comp.arch
  7. Organization: Inst. f. Neuroinformatik, Ruhr-Universitaet Bochum, FRG
  8. References: <1992Dec18.175402.27841@hubcap.clemson.edu>
  9. Date: 22 Dec 92 18:33:54
  10. Lines: 45
  11.  
  12.    In article <1992Dec18.175402.27841@hubcap.clemson.edu>
  13.    dfk@wildcat.dartmouth.edu (David Kotz) writes:
  14.  
  15.    I have a question about DMA devices, specifically for networks and disks.
  16.  
  17.    Do you know if it is possible (and if so, common) for a DMA device to
  18.    support scatter/gather? In particular, I'm trying to model a multiprocessor
  19.    interconnect network interface, and it would be very helpful if I could
  20.    avoid packetization by specifying the addresses and lengths of my message
  21.    header and message body, for the network DMA to pick up. I'm guessing that
  22.    this is not usually an option.
  23.  
  24.    Also, in a disk interface, can it read in a whole track but scatter the
  25.    blocks to different locations in memory? I'm guessing that this kind of
  26.    thing is more common.
  27.  
  28. Well, as a historical perpective on this subject, consider what the I/O
  29. adapters of the Vax11/780 (ca. 1978?) did/do: They (Unibus and Massbus
  30. adapters) had a set of socalled mapping registers. These mapped an offset in
  31. an I/O transaction into the appropriate _physical_ address. A set of system
  32. routines was provided for drivers to load the mapping registers from the page
  33. table of a process (or system space) with the required data.  (I think there
  34. are seperate routines to make sure the page tables contain valid entries in
  35. the relevant page range, which is especially important for I/O directly
  36. to/from user space. I do know there was an optimization for reads which didn't
  37. bother to page in pages from backing store which were going to be overwritten
  38. shortly by a read  it just substituted a page from the free list and marked
  39. the page table entry as dirty.)
  40.  
  41. A number of smaller Vaxen (only the uVaxI? or also the 725/730?) didn't have
  42. these and in general had to do I/O a page at a time...probably still slightly
  43. faster than a PC/XT :).
  44.  
  45. A later adapter, the one for the CI (computer interconnect, four cables
  46. running at 70Mbit/s each) went even further: It reads I/O request packets from
  47. system virtual memory, containing pointers to buffers in virtual memory (I
  48. think user space buffers are double mapped into system space), and reads the
  49. page tables itself in order to determine physical addresses.  Sort of like a
  50. closely coupled multiprocessor with one processor dedicated to I/O. (The
  51. rumour was that for the 750, the CI adapter was actually the faster CPU...)
  52.  
  53. So this is quite an old trick, and not really that difficult to do.  I would
  54. assume that current Unix/workstation systems do something similar.
  55.  
  56.     Jan
  57.