OpenCores
URL https://opencores.org/ocsvn/or1k/or1k/trunk

Subversion Repositories or1k

[/] [or1k/] [trunk/] [ecos-2.0/] [doc/] [html/] [ref/] [io-eth-call-graph.html] - Blame information for rev 1765

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 1254 phoenix
<!-- 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.               -->
9
<HTML
10
><HEAD
11
><TITLE
12
>Calling graph for Transmission and Reception</TITLE
13
><meta name="MSSmartTagsPreventParsing" content="TRUE">
14
<META
15
NAME="GENERATOR"
16
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
17
"><LINK
18
REL="HOME"
19
TITLE="eCos Reference Manual"
20
HREF="ecos-ref.html"><LINK
21
REL="UP"
22
TITLE="Generic Ethernet Device Driver"
23
HREF="io-eth-drv-generic1.html"><LINK
24
REL="PREVIOUS"
25
TITLE="Upper Layer Functions"
26
HREF="io-eth-drv-upper-api.html"><LINK
27
REL="NEXT"
28
TITLE="SNMP"
29
HREF="net-snmp.html"></HEAD
30
><BODY
31
CLASS="SECT1"
32
BGCOLOR="#FFFFFF"
33
TEXT="#000000"
34
LINK="#0000FF"
35
VLINK="#840084"
36
ALINK="#0000FF"
37
><DIV
38
CLASS="NAVHEADER"
39
><TABLE
40
SUMMARY="Header navigation table"
41
WIDTH="100%"
42
BORDER="0"
43
CELLPADDING="0"
44
CELLSPACING="0"
45
><TR
46
><TH
47
COLSPAN="3"
48
ALIGN="center"
49
>eCos Reference Manual</TH
50
></TR
51
><TR
52
><TD
53
WIDTH="10%"
54
ALIGN="left"
55
VALIGN="bottom"
56
><A
57
HREF="io-eth-drv-upper-api.html"
58
ACCESSKEY="P"
59
>Prev</A
60
></TD
61
><TD
62
WIDTH="80%"
63
ALIGN="center"
64
VALIGN="bottom"
65
>Chapter 46. Generic Ethernet Device Driver</TD
66
><TD
67
WIDTH="10%"
68
ALIGN="right"
69
VALIGN="bottom"
70
><A
71
HREF="net-snmp.html"
72
ACCESSKEY="N"
73
>Next</A
74
></TD
75
></TR
76
></TABLE
77
><HR
78
ALIGN="LEFT"
79
WIDTH="100%"></DIV
80
><DIV
81
CLASS="SECT1"
82
><H1
83
CLASS="SECT1"
84
><A
85
NAME="IO-ETH-CALL-GRAPH">Calling graph for Transmission and Reception</H1
86
><P
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 &#8220;foreground&#8221; when something asynchronous has occurred.</P
90
><DIV
91
CLASS="SECT2"
92
><H2
93
CLASS="SECT2"
94
><A
95
NAME="IO-ETH-CALL-GRAPH-TX">Transmission</H2
96
><P
97
></P
98
><OL
99
TYPE="1"
100
><LI
101
><P
102
>Some foreground task such as the application, SNMP &#8220;daemon&#8221;,
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 &#8220;ping&#8221; or <SPAN
106
CLASS="ACRONYM"
107
>ARP</SPAN
108
> request.</P
109
></LI
110
><LI
111
><P
112
>The driver calls the
113
<TT
114
CLASS="FUNCTION"
115
><TT
116
CLASS="REPLACEABLE"
117
><I
118
>HRDWR</I
119
></TT
120
>_can_send()</TT
121
>
122
function in the hardware driver.</P
123
></LI
124
><LI
125
><P
126
><TT
127
CLASS="FUNCTION"
128
><TT
129
CLASS="REPLACEABLE"
130
><I
131
>HRDWR</I
132
></TT
133
>_can_send()</TT
134
>
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
141
></LI
142
><LI
143
><P
144
>If it can send right now, <TT
145
CLASS="REPLACEABLE"
146
><I
147
>HRDWR</I
148
></TT
149
>_send() is called.
150
<TT
151
CLASS="FUNCTION"
152
><TT
153
CLASS="REPLACEABLE"
154
><I
155
>HRDWR</I
156
></TT
157
>_send()</TT
158
> copies the
159
data into special hardware buffers, or instructs the hardware to
160
&#8220;send that.&#8221; It also remembers the key that is associated with
161
this tx request.</P
162
></LI
163
><LI
164
><P
165
>These calls return &#8230; time passes &#8230;</P
166
></LI
167
><LI
168
><P
169
>Asynchronously, the hardware makes an interrupt to say
170
&#8220;transmit is done.&#8221;
171
The ISR quietens the interrupt source in the hardware and
172
requests that the associated DSR be run.</P
173
></LI
174
><LI
175
><P
176
>The DSR calls (or <SPAN
177
CLASS="emphasis"
178
><I
179
CLASS="EMPHASIS"
180
>is</I
181
></SPAN
182
>) the
183
<TT
184
CLASS="FUNCTION"
185
>eth_drv_dsr()</TT
186
> function in the generic driver.</P
187
></LI
188
><LI
189
><P
190
><TT
191
CLASS="FUNCTION"
192
>eth_drv_dsr()</TT
193
> in the generic driver awakens the
194
&#8220;Network Delivery Thread&#8221; which calls the deliver function
195
<TT
196
CLASS="REPLACEABLE"
197
><I
198
>HRDWR</I
199
></TT
200
>_deliver() in the driver.</P
201
></LI
202
><LI
203
><P
204
>The deliver function realizes that a transmit request has completed,
205
and calls the callback tx-done function
206
<TT
207
CLASS="FUNCTION"
208
>(sc-&#62;funs-&#62;eth_drv-&#62;tx_done)()</TT
209
>
210
with the same key that it remembered for this tx.</P
211
></LI
212
><LI
213
><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
218
></LI
219
><LI
220
><P
221
>The callback tx-done function
222
also enquires whether <TT
223
CLASS="REPLACEABLE"
224
><I
225
>HRDWR</I
226
></TT
227
>_can_send() now says
228
&#8220;yes, we can send&#8221;
229
and if so, dequeues a further transmit request
230
which may have been queued as described above.  If so, then
231
<TT
232
CLASS="REPLACEABLE"
233
><I
234
>HRDWR</I
235
></TT
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 &#8220;Network Delivery Thread&#8221;
239
which then sleeps, awaiting the next asynchronous event.</P
240
></LI
241
><LI
242
><P
243
>All done &#8230;</P
244
></LI
245
></OL
246
></DIV
247
><DIV
248
CLASS="SECT2"
249
><H2
250
CLASS="SECT2"
251
><A
252
NAME="IO-ETH-CALL-GRAPH-RX">Receive</H2
253
><P
254
></P
255
><OL
256
TYPE="1"
257
><LI
258
><P
259
>Asynchronously, the hardware makes an interrupt to say
260
&#8220;there is ready data in a receive buffer.&#8221;
261
The ISR quietens the interrupt source in the hardware and
262
requests that the associated DSR be run.</P
263
></LI
264
><LI
265
><P
266
>The DSR calls (or <SPAN
267
CLASS="emphasis"
268
><I
269
CLASS="EMPHASIS"
270
>is</I
271
></SPAN
272
>) the
273
<TT
274
CLASS="FUNCTION"
275
>eth_drv_dsr()</TT
276
> function in the generic driver.</P
277
></LI
278
><LI
279
><P
280
><TT
281
CLASS="FUNCTION"
282
>eth_drv_dsr()</TT
283
> in the generic driver awakens the
284
&#8220;Network Delivery Thread&#8221; which calls the deliver function
285
<TT
286
CLASS="REPLACEABLE"
287
><I
288
>HRDWR</I
289
></TT
290
>_deliver() in the driver.</P
291
></LI
292
><LI
293
><P
294
>The deliver function realizes that there is data ready and calls
295
the callback receive function
296
<TT
297
CLASS="FUNCTION"
298
>(sc-&#62;funs-&#62;eth_drv-&#62;recv)()</TT
299
>
300
to tell it how many bytes to prepare for.</P
301
></LI
302
><LI
303
><P
304
>The callback receive function allocates memory within the stack
305
(eg. <SPAN
306
CLASS="TYPE"
307
>MBUFs</SPAN
308
> in BSD/Unix style stacks) and prepares
309
a set of scatter-gather buffers that can
310
accommodate the packet.</P
311
></LI
312
><LI
313
><P
314
>It then calls back into the hardware driver routine
315
<TT
316
CLASS="REPLACEABLE"
317
><I
318
>HRDWR</I
319
></TT
320
>_recv().
321
<TT
322
CLASS="REPLACEABLE"
323
><I
324
>HRDWR</I
325
></TT
326
>_recv() must copy the data from the
327
hardware's buffers into the scatter-gather buffers provided, and return.</P
328
></LI
329
><LI
330
><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
&#8220;Network Delivery Thread&#8221;
335
sleeps once more, awaiting the next asynchronous event.</P
336
></LI
337
></OL
338
></DIV
339
></DIV
340
><DIV
341
CLASS="NAVFOOTER"
342
><HR
343
ALIGN="LEFT"
344
WIDTH="100%"><TABLE
345
SUMMARY="Footer navigation table"
346
WIDTH="100%"
347
BORDER="0"
348
CELLPADDING="0"
349
CELLSPACING="0"
350
><TR
351
><TD
352
WIDTH="33%"
353
ALIGN="left"
354
VALIGN="top"
355
><A
356
HREF="io-eth-drv-upper-api.html"
357
ACCESSKEY="P"
358
>Prev</A
359
></TD
360
><TD
361
WIDTH="34%"
362
ALIGN="center"
363
VALIGN="top"
364
><A
365
HREF="ecos-ref.html"
366
ACCESSKEY="H"
367
>Home</A
368
></TD
369
><TD
370
WIDTH="33%"
371
ALIGN="right"
372
VALIGN="top"
373
><A
374
HREF="net-snmp.html"
375
ACCESSKEY="N"
376
>Next</A
377
></TD
378
></TR
379
><TR
380
><TD
381
WIDTH="33%"
382
ALIGN="left"
383
VALIGN="top"
384
>Upper Layer Functions</TD
385
><TD
386
WIDTH="34%"
387
ALIGN="center"
388
VALIGN="top"
389
><A
390
HREF="io-eth-drv-generic1.html"
391
ACCESSKEY="U"
392
>Up</A
393
></TD
394
><TD
395
WIDTH="33%"
396
ALIGN="right"
397
VALIGN="top"
398
>SNMP</TD
399
></TR
400
></TABLE
401
></DIV
402
></BODY
403
></HTML
404
>

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.