summaryrefslogtreecommitdiffstats
path: root/Documentation/networking/NAPI_HOWTO.txt
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/networking/NAPI_HOWTO.txt')
-rw-r--r--Documentation/networking/NAPI_HOWTO.txt12
1 files changed, 6 insertions, 6 deletions
diff --git a/Documentation/networking/NAPI_HOWTO.txt b/Documentation/networking/NAPI_HOWTO.txt
index 93af3e87c65b..c300f26a2772 100644
--- a/Documentation/networking/NAPI_HOWTO.txt
+++ b/Documentation/networking/NAPI_HOWTO.txt
@@ -95,8 +95,8 @@ There are two types of event register ACK mechanisms.
Move all to dev->poll()
C) Ability to detect new work correctly.
-NAPI works by shutting down event interrupts when theres work and
-turning them on when theres none.
+NAPI works by shutting down event interrupts when there's work and
+turning them on when there's none.
New packets might show up in the small window while interrupts were being
re-enabled (refer to appendix 2). A packet might sneak in during the period
we are enabling interrupts. We only get to know about such a packet when the
@@ -114,7 +114,7 @@ Locking rules and environmental guarantees
only one CPU can pick the initial interrupt and hence the initial
netif_rx_schedule(dev);
- The core layer invokes devices to send packets in a round robin format.
-This implies receive is totaly lockless because of the guarantee only that
+This implies receive is totally lockless because of the guarantee that only
one CPU is executing it.
- contention can only be the result of some other CPU accessing the rx
ring. This happens only in close() and suspend() (when these methods
@@ -510,7 +510,7 @@ static int my_poll (struct net_device *dev, int *budget)
an interrupt will be generated */
goto done;
}
- /* done! at least thats what it looks like ;->
+ /* done! at least that's what it looks like ;->
if new packets came in after our last check on status bits
they'll be caught by the while check and we go back and clear them
since we havent exceeded our quota */
@@ -678,10 +678,10 @@ routine:
CSR5 bit of interest is only the rx status.
If you look at the last if statement:
you just finished grabbing all the packets from the rx ring .. you check if
-status bit says theres more packets just in ... it says none; you then
+status bit says there are more packets just in ... it says none; you then
enable rx interrupts again; if a new packet just came in during this check,
we are counting that CSR5 will be set in that small window of opportunity
-and that by re-enabling interrupts, we would actually triger an interrupt
+and that by re-enabling interrupts, we would actually trigger an interrupt
to register the new packet for processing.
[The above description nay be very verbose, if you have better wording