PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") (11/15/87)
Has anyone come up with a strategy for non-blocking sends in the device drivers? Is this plausible? My thoughts are that some added performance might be gotten if the send routine didn't have to wait for the device to complete sending. One of the devices that I am hacking on has a means to interrupt when transmission is complete, so I thought enqueing out-going packets might be feasible. -Philip
brad@cayman.UUCP (Brad Parker) (11/16/87)
I'm new to this group, so please forgive any bogosities... (or is that "bozosities"? ;=) I've been reading the mail back and forth about a "standard" interface to tcp/ip under ms-dos. Coming from the macintosh side of things, I'd be interested in people's reactions to a mac-style solution. Driver I/O on the macintosh is handled via "request blocks" which contain all of the the pertinent information, including pointers to the data buffers. Requests can be issued either synchronously or asynchronously. Async requests can specify an "upcall" routine to be called when the request completes (we call them completion routines). It is entirely possible to implement the "Berkeley socket" abstraction using this "request block" scheme *and* satisfy some the other problems such as non-blocking i/o. In fact, it's possible to implement a more general socket scheme which is (or appears to be ?) a superset of the the Berkeley implementation, allowing one to support more protocols than just the IP domain (for I fear I hear the call of I-S-O a 'commin). Not being "very hip" to the ms-dos low-level world, I'm curious if this type of scheme is possible under ms-dos? (actually, I'm more interested if it could be done under ms-dos *and* OS/and-here's-the-kitchen-sink-2) Brad Parker Cayman Systems harvard!cayman!brad
watstar@watale.waterloo.EDU (Michael Shiels - WatStar/pc Network Project) (11/16/87)
You can get interrupts on transmission complete for 3com 3c501 ethernet cards but I have never seen a driver written to use it. You could then queue up outgoing packets and make the driver much more efficient
jbvb@ftp.UUCP (James Van Bokkelen) (11/16/87)
Unless Drew has changed the handling of packet buffers a good deal, you'd be best guided by the structure of the MIT code: the driver send routine can't return until the packet has been copied out of the PC/IP packet buffer (DMA or memcpy() to the board complete). jbvb
ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (11/17/87)
Sure it's possible under MS/DOS and OS/2. As a matter of fact, that is how NETBIOS works. Drew
ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (11/17/87)
You definitely don't want to do that. All the upper level code (especially TCP) depends on the fact that once they've done a send they can muck with the packet all they want. If you haven't copied the packet to the board or to another area of memory it may get trampled before it gets sent. Also, you probably don't want to play with the 3com 3c501 tx interrupts. No one has ever been able to get them working correctly in all possible cases. Drew
BORGY@UMDB.BITNET (11/17/87)
Please if there is anyone out that can get me off this mailing list I would be forever thankful!!!!!!!!!!!!!!!!!