Lines Matching refs:the

11 This document sketches the structure of portions of the spidernet
12 device driver in the Linux kernel tree. The spidernet is a gigabit
13 ethernet device built into the Toshiba southbridge commonly used
14 in the SONY Playstation 3 and the IBM QS20 Cell blade.
16 The Structure of the RX Ring.
19 together with three pointers into the ring that are used to manage its
22 The elements of the ring are called "descriptors" or "descrs"; they
23 describe the received data. This includes a pointer to a buffer
24 containing the received data, the buffer size, and various status bits.
28 to receive data from the hardware. A "full" descriptor has data in it,
29 and is waiting to be emptied and processed by the OS. A "not-in-use"
33 During normal operation, on device startup, the OS (specifically, the
36 ring is handed off to the hardware, which sequentially fills in the
37 buffers, and marks them "full". The OS follows up, taking the full
40 This filling and emptying is managed by three pointers, the "head"
41 and "tail" pointers, managed by the OS, and a hardware current
42 descriptor pointer (GDACTDPA). The GDACTDPA points at the descr
43 currently being filled. When this descr is filled, the hardware
44 marks it full, and advances the GDACTDPA by one.  Thus, when there is
46 and everything in front of it should be "empty".  If the hardware
47 discovers that the current descr is not empty, it will signal an
50 The tail pointer tails or trails the hardware pointer. When the
51 hardware is ahead, the tail pointer will be pointing at a "full"
53 and advance the tail pointer.  Thus, when there is flowing RX traffic,
54 all of the descrs in front of the tail pointer should be "full", and
56 flowing, then the tail pointer can catch up to the hardware pointer.
57 The OS will then note that the current tail is "empty", and halt
60 The head pointer (somewhat mis-named) follows after the tail pointer.
61 When traffic is flowing, then the head pointer will be pointing at
64 dma-mapping it so as to make it visible to the hardware. The OS will
65 then mark the descr as "empty", ready to receive data. Thus, when there
66 is flowing RX traffic, everything in front of the head pointer should
68 RX traffic is flowing, then the head pointer can catch up to the tail
69 pointer, at which point the OS will notice that the head descr is
72 Thus, in an idle system, the GDACTDPA, tail and head pointers will
73 all be pointing at the same descr, which should be "empty". All of the
74 other descrs in the ring should be "empty" as well.
76 The show_rx_chain() routine will print out the locations of the
77 GDACTDPA, tail and head pointers. It will also summarize the contents
78 of the ring, starting at the tail pointer, and listing the status
79 of the descrs that follow.
81 A typical example of the output, for a nearly idle system, might be
91 In the above, the hardware has filled in one descr, number 20. Both
95 The "Have nnn decrs" refers to the descr starting at the tail: in this
97 to all of the rest of the descrs, from the last status change. The "nnn"
98 is a count of how many descrs have exactly the same status.
103 In the device driver source code, a different set of names are
114 As long as the OS can empty out the RX buffers at a rate faster than
115 the hardware can fill them, there is no problem. If, for some reason,
116 the OS fails to empty the RX ring fast enough, the hardware GDACTDPA
117 pointer will catch up to the head, notice the not-empty condition,
118 ad stop. However, RX packets may still continue arriving on the wire.
120 When this local ram fills up, the spider chip will issue an interrupt
121 indicating this (GHIINT0STS will show ERRINT, and the GRMFLLINT bit
122 will be set in GHIINT1STS).  When the RX ram full condition occurs,
124 This section describes the special handling for this condition.
126 When the OS finally has a chance to run, it will empty out the RX ring.
127 In particular, it will clear the descriptor on which the hardware had
128 stopped. However, once the hardware has decided that a certain
130 it will restart at the next descr. This potentially will lead to a
131 deadlock condition, as the tail pointer will be pointing at this descr,
132 which, from the OS point of view, is empty; the OS will be waiting for
133 this descr to be filled. However, the hardware has skipped this descr,
134 and is filling the next descrs. Since the OS doesn't see this, there
135 is a potential deadlock, with the OS waiting for one descr to fill,
136 while the hardware is waiting for a different set of descrs to become
139 A call to show_rx_chain() at this point indicates the nature of the
140 problem. A typical print when the network is hung shows the following:
154 Both the tail and head pointers are pointing at descr 255, which is
155 marked xa... which is "empty". Thus, from the OS point of view, there
156 is nothing to be done. In particular, there is the implicit assumption
157 that everything in front of the "empty" descr must surely also be empty,
158 as explained in the last section. The OS is waiting for descr 255 to
162 Since its already full, the hardware can do nothing more, and thus has
165 descr 254, since tail was at 255.) Thus, the system is deadlocked,
166 and there can be no forward progress; the OS thinks there's nothing
167 to do, and the hardware has nowhere to put incoming data.
169 This bug/feature is worked around with the spider_net_resync_head_ptr()
170 routine. When the driver receives RX interrupts, but an examination
171 of the RX chain seems to show it is empty, then it is probable that
172 the hardware has skipped a descr or two (sometimes dozens under heavy
174 search the ring for the next full descr, and the driver will resume
175 operations there.  Since this will leave "holes" in the ring, there
178 As of this writing, the spider_net_resync() strategy seems to work very
185 the TX queue is appropriately serviced for large packet sizes.
187 For packet sizes greater than about 1KBytes, the kernel can fill
188 the TX ring quicker than the device can drain it. Once the ring
189 is full, the netdev is stopped. When there is room in the ring,
190 the netdev needs to be reawakened, so that more TX packets are placed
191 in the ring. The hardware can empty the ring about four times per jiffy,
192 so its not appropriate to wait for the poll routine to refill, since
193 the poll routine runs only once per jiffy.  The low-watermark mechanism
194 marks a descr about 1/4th of the way from the bottom of the queue, so
195 that an interrupt is generated when the descr is processed. This
196 interrupt wakes up the netdev, which can then refill the queue.
199 interrupts, as the hardware can empty the queue faster than the kernel