From: eengelke@sail.uwaterloo.ca (Erick Engelke)
Subject: Re: Packet driver question
Organization: University of Waterloo
Date: Thu, 9 Apr 1992 21:45:28 GMT

> PPH93@DMSWWU1A.BITNET (Thomas Heller) writes:
>>Is it safe to call send_pkt() from the (second) upcall to the receiver()
>>function?
>>
>>I tried this once and it worked, but pkttrace became confused.

and I wrote my favourite rules for writing packet driver software. Since there
have been some E-mail questions, here are some explanations: 

>Inside a packet driver upcall,...
>1. No transmits - some cards would require interrupts to transmit and we are already
>   (possibly) inside an interrupt so the transmit interrupt might be ignored and have
>   entirely unpredictable results.

    Some cards have separate input and output machines but why assume that they do?
    Also, cards which have DMA i/o may incur difficulties if you do a transmit inside
    an interrupt.  
    
    In fact, doing a transmission during any interrupt is a test of luck if
    the user happens to be running anything else which may use the same packet
    (or ODI or NDIS) driver.  Suppose the user is doing Novell file i/o and is in 
    the process of writing a packet to the output buffer and your program interrupts
    that operation to write out a packet.  When you finish sending your packet you
    return to their sending routine which then will output an incomplete packet.  How
    quickly it realizes this and retransmits the buffer usually depends on the network
    filesystem's timeout mechanism.

    Some packet drivers solve this using a semaphore to simply return a SEND FAILED,
    but some do not.

    I've tried both of the above.  I've needed both of the above (at times).  I've
    seen both of the above fail.


>9. Don't do any real processing, some packet drivers temporarily leave the card in a weird
>   state for the duration of the upcall because they expect you will only execute a dozen
>   or so instructions.

    For example, on token ring systems (eg 4Mbps, FDDI, the copper FDDI thing whose
    name I forget, etc.) the packet always gets returned to the sender's card
    and so there is a bit informing the sender that the receiver has actually
    received the packet.  If the receiver's buffers were full on the receiving side
    it will usually not toggle the bit, so the sender will attempt to retransmit 
    repeatedly until the packet can be accepted.

    Suppose your application takes its time on the upcalls, you are not allowing the
    packet driver to clear out its buffers so you are causing refusals and hence 
    unnecessary retransmits and thus clogging up the ring with repeat traffic.

    On Ethernet systems you may be preventing the packet driver from getting back
    to handling packets so you may be dropping frames and thus sacrificing
    throughput while wasting media time.  

>
>I suggest that you take the approach of SIMPLEST is BEST.  Merely buffer the packet and
>process it later by implementing one of:
>1. Polling - just poll for packets constantly
>2. Poll on some regular interval - eg. tye to clock tick
>3. Poll after a network card interrupt by chaining to the network card's ISR.  I don't 
>   recommend this, but it is better than some other options.

  Why not do #3?  Think of non-routine packet drivers such as ETHERSLIP, there is no
  hardware interrupt which occurs exactly once during a packet transfer.  Instead you
  have a many interrupts occuring for every packet.

  One may say, "I support SLIP separately, I don't need to support ETHERSLIP", 
  ETHERSLIP is the only way to support PKTMUX. Or maybe the user needs to use a 
  different service such as a PPP-like thing for which he has a packet driver.

  There is also the problem I mentioned at the start of this post, of how you are
  inviting problems if the operation involves another program which uses the same
  network card.  For this reason I've seen some really pathetic FTP performance from
  two of the commercial TCPs when writing to network drives.  Packet drivers which
  don't use semaphores cause the network file system to timeout and seem really slow.

Erick

-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca
Newsgroups: comp.protocols.tcp-ip.ibmpc