Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!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: <8805160419.AA08121@vax.ftp.com>
Date: 16 May 88 04:19:47 GMT
References: <8805152142.aa05116@Louie.UDEL.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 28

Depends on how long the transfer takes.  Regardless of CPU speed, the
DMA controller has to access the same memory, and it can only do it
as fast as the bus allows, implying that the 80386 executes 3 or more
wait states for each DMA cycle.  As I said earlier, most packets
are only 60 or 70 bytes long (although when doing bulk data transfer,
you will see two peaks, and there ought to be more 1078-byte or larger
data packets than acks, at least for portions of the transfer).

Given that it might take 100 or more instructions to save and queue the state,
get out of this ISR, get into the DMA ISR and pick up the state again, it
is pretty clear that there is no point in the extra complexity of doing two
context switches while the DMA controller moves 60 or 70 bytes.  If the driver
must support both DMA and programmed I/O, only a programmer who is neither
hurried, nor worried about code size, will bother to implement the context
switch for larger packets.

On fast processors, the speed increase from using programmed I/O will probably
dominate.  Even when the fast processor has something useful to do in the
interrupted context, the increase in complexity (a second ISR; keeping the DMA
controller modes straight with the BIOS, if it is in use; the fact that the
2nd interrupt entry actually slows down packet processing a little) makes it
an unlikely implementation decision.

In summary, yes, there might be a small benefit.  But, the PC was designed
cheap, not fast, and the combination of its architecture and the nature
of network I/O make it an unrewarding tradeoff.

jbvb