It may be worth clarifying further the flow of control in the transmit and receive cases, where the hardware driver does use interrupts and so DSRs to tell the “foreground” when something asynchronous has occurred.
Some foreground task such as the application, SNMP “daemon”, DHCP management thread or whatever, calls into network stack to send a packet, or the stack decides to send a packet in response to incoming traffic such as a “ping” or ARP request.
The driver calls the
HRDWR_can_send()
function in the hardware driver.
HRDWR_can_send()
returns the number of available "slots" in which it
can store a pending transmit packet.
If it cannot send at this time, the packet is queued outside the
hardware driver for later; in this case, the hardware is already busy
transmitting, so expect an interrupt as described below for completion
of the packet currently outgoing.
If it can send right now, HRDWR_send() is called.
HRDWR_send() copies the
data into special hardware buffers, or instructs the hardware to
“send that.” It also remembers the key that is associated with
this tx request.
These calls return … time passes …
Asynchronously, the hardware makes an interrupt to say “transmit is done.” The ISR quietens the interrupt source in the hardware and requests that the associated DSR be run.
The DSR calls (or is) the
eth_drv_dsr() function in the generic driver.
eth_drv_dsr() in the generic driver awakens the
“Network Delivery Thread” which calls the deliver function
HRDWR_deliver() in the driver.
The deliver function realizes that a transmit request has completed,
and calls the callback tx-done function
(sc->funs->eth_drv->tx_done)()
with the same key that it remembered for this tx.
The callback tx-done function uses the key to find the resources associated with this transmit request; thus the stack knows that the transmit has completed and its resources can be freed.
The callback tx-done function also enquires whether HRDWR_can_send() now says “yes, we can send” and if so, dequeues a further transmit request which may have been queued as described above. If so, then HRDWR_send() copies the data into the hardware buffers, or instructs the hardware to "send that" and remembers the new key, as above. These calls then all return to the “Network Delivery Thread” which then sleeps, awaiting the next asynchronous event.
All done …
Asynchronously, the hardware makes an interrupt to say “there is ready data in a receive buffer.” The ISR quietens the interrupt source in the hardware and requests that the associated DSR be run.
The DSR calls (or is) the
eth_drv_dsr() function in the generic driver.
eth_drv_dsr() in the generic driver awakens the
“Network Delivery Thread” which calls the deliver function
HRDWR_deliver() in the driver.
The deliver function realizes that there is data ready and calls
the callback receive function
(sc->funs->eth_drv->recv)()
to tell it how many bytes to prepare for.
The callback receive function allocates memory within the stack (eg. MBUFs in BSD/Unix style stacks) and prepares a set of scatter-gather buffers that can accommodate the packet.
It then calls back into the hardware driver routine HRDWR_recv(). HRDWR_recv() must copy the data from the hardware's buffers into the scatter-gather buffers provided, and return.
The network stack now has the data in-hand, and does with it what it will. This might include recursive calls to transmit a response packet. When this all is done, these calls return, and the “Network Delivery Thread” sleeps once more, awaiting the next asynchronous event.