1 <!-- Copyright (C) 2003 Red Hat, Inc. -->
2 <!-- This material may be distributed only subject to the terms -->
3 <!-- and conditions set forth in the Open Publication License, v1.0 -->
4 <!-- or later (the latest version is presently available at -->
5 <!-- http://www.opencontent.org/openpub/). -->
6 <!-- Distribution of the work or derivative of the work in any -->
7 <!-- standard (paper) book form is prohibited unless prior -->
8 <!-- permission is obtained from the copyright holder. -->
12 >Calling graph for Transmission and Reception</TITLE
13 ><meta name="MSSmartTagsPreventParsing" content="TRUE">
16 CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
19 TITLE="eCos Reference Manual"
20 HREF="ecos-ref.html"><LINK
22 TITLE="Generic Ethernet Device Driver"
23 HREF="io-eth-drv-generic1.html"><LINK
25 TITLE="Upper Layer Functions"
26 HREF="io-eth-drv-upper-api.html"><LINK
29 HREF="net-snmp.html"></HEAD
40 SUMMARY="Header navigation table"
49 >eCos Reference Manual</TH
57 HREF="io-eth-drv-upper-api.html"
65 >Chapter 46. Generic Ethernet Device Driver</TD
85 NAME="IO-ETH-CALL-GRAPH">Calling graph for Transmission and Reception</H1
87 >It may be worth clarifying further the flow of control in the transmit and
88 receive cases, where the hardware driver does use interrupts and so DSRs to
89 tell the “foreground” when something asynchronous has occurred.</P
95 NAME="IO-ETH-CALL-GRAPH-TX">Transmission</H2
102 >Some foreground task such as the application, SNMP “daemon”,
103 DHCP management thread or whatever, calls into network stack to send a
104 packet, or the stack decides to send a packet in response to incoming
105 traffic such as a “ping” or <SPAN
112 >The driver calls the
122 function in the hardware driver.</P
135 returns the number of available "slots" in which it
136 can store a pending transmit packet.
137 If it cannot send at this time, the packet is queued outside the
138 hardware driver for later; in this case, the hardware is already busy
139 transmitting, so expect an interrupt as described below for completion
140 of the packet currently outgoing.</P
144 >If it can send right now, <TT
159 data into special hardware buffers, or instructs the hardware to
160 “send that.” It also remembers the key that is associated with
165 >These calls return … time passes …</P
169 >Asynchronously, the hardware makes an interrupt to say
170 “transmit is done.”
171 The ISR quietens the interrupt source in the hardware and
172 requests that the associated DSR be run.</P
176 >The DSR calls (or <SPAN
186 > function in the generic driver.</P
193 > in the generic driver awakens the
194 “Network Delivery Thread” which calls the deliver function
200 >_deliver() in the driver.</P
204 >The deliver function realizes that a transmit request has completed,
205 and calls the callback tx-done function
208 >(sc->funs->eth_drv->tx_done)()</TT
210 with the same key that it remembered for this tx.</P
214 >The callback tx-done function
215 uses the key to find the resources associated with
216 this transmit request; thus the stack knows that the transmit has
217 completed and its resources can be freed.</P
221 >The callback tx-done function
222 also enquires whether <TT
227 >_can_send() now says
228 “yes, we can send”
229 and if so, dequeues a further transmit request
230 which may have been queued as described above. If so, then
236 >_send() copies the data into the hardware buffers, or
237 instructs the hardware to "send that" and remembers the new key, as above.
238 These calls then all return to the “Network Delivery Thread”
239 which then sleeps, awaiting the next asynchronous event.</P
252 NAME="IO-ETH-CALL-GRAPH-RX">Receive</H2
259 >Asynchronously, the hardware makes an interrupt to say
260 “there is ready data in a receive buffer.”
261 The ISR quietens the interrupt source in the hardware and
262 requests that the associated DSR be run.</P
266 >The DSR calls (or <SPAN
276 > function in the generic driver.</P
283 > in the generic driver awakens the
284 “Network Delivery Thread” which calls the deliver function
290 >_deliver() in the driver.</P
294 >The deliver function realizes that there is data ready and calls
295 the callback receive function
298 >(sc->funs->eth_drv->recv)()</TT
300 to tell it how many bytes to prepare for.</P
304 >The callback receive function allocates memory within the stack
308 > in BSD/Unix style stacks) and prepares
309 a set of scatter-gather buffers that can
310 accommodate the packet.</P
314 >It then calls back into the hardware driver routine
326 >_recv() must copy the data from the
327 hardware's buffers into the scatter-gather buffers provided, and return.</P
331 >The network stack now has the data in-hand, and does with it what it will.
332 This might include recursive calls to transmit a response packet.
333 When this all is done, these calls return, and the
334 “Network Delivery Thread”
335 sleeps once more, awaiting the next asynchronous event.</P
345 SUMMARY="Footer navigation table"
356 HREF="io-eth-drv-upper-api.html"
384 >Upper Layer Functions</TD
390 HREF="io-eth-drv-generic1.html"