Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!eos!labrea!agate!ucbvax!vax.ftp.COM!jbvb
From: jbvb@vax.ftp.COM (James Van Bokkelen)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: DMA usage with network I/O
Message-ID: <8805150536.AA05884@vax.ftp.com>
Date: 15 May 88 05:36:45 GMT
References: <8805142050.aa15574@Louie.UDEL.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 22

The scenario works like this: The network interface interrupts,  The interrupt
service routine gets invoked, figures out where to put the data, starts DMA.
At this point, the ISR could return, and let packet processing continue when
the DMA completion interrupt happens (the packet needs to be queued for some
sort of demultiplexor to ponder it).  However, the packet is probably only
60 or 70 bytes long (normal Ethernet traffic), and the DMA will be done
almost before the ISR can return.  So, in the standard PC/IP device driver
architecture, the ISR spins, waiting for DMA complete.  Then it continues
processing the packet.

Given this architecture, DMA only brings a benefit when it is faster than
string I/O (which is true in 8088-based machines).  In the classic situation
of a minicomputer disk interface, DMA got you a lot, because once a seek
completed, you could just tell the drive to get sector X to address Y, and
interrupt when done.  The O/S had plenty of time to do something else while
rotational latency took its toll.  With incoming packets, you don't know
how long they are, etc., and the PC's lusing DMA architecture doesn't allow
you to do set-up prior to actual need.  On transmitted packets, DMA would
be useful if you could tell the interface to transmit on DMA complete, but
you can't with any I've seen so far...

James VanBokkelen
FTP Software Inc.