| To: | tleete@xxxxxxxxxxxx |
|---|---|
| Subject: | Re: [PATCH] ipv4 skbuff locking scope |
| From: | "David S. Miller" <davem@xxxxxxxxxx> |
| Date: | Mon, 30 Oct 2000 20:03:24 -0800 |
| Cc: | linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <39FE39EF.62CC880B@mountain.net> (message from Tom Leete on Mon, 30 Oct 2000 22:18:07 -0500) |
| References: | <39FDF518.A9F1204D@mountain.net> <200010302224.OAA02266@pizda.ninka.net> <39FE39EF.62CC880B@mountain.net> |
| Sender: | owner-netdev@xxxxxxxxxxx |
Date: Mon, 30 Oct 2000 22:18:07 -0500 From: Tom Leete <tleete@xxxxxxxxxxxx> > Look, if the sleep condition test "races" due to not holding the > lock, the schedule() just returns because if the sleep condidion > test passes then by definition this means we were also woken up, > see? Would you explain what is accomplished by toggling the lock every time through? What breaks by not doing so? Incoming packets are not processed while the lock is held, they get queued to the backlog. When the lock is released, the backlog packets get processed. For a TCP sender, these backlog packets are ACKs making room in the send buffer so that the application can put more data into the send buffer. Later, David S. Miller davem@xxxxxxxxxx |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH] ipv4 skbuff locking scope, Tom Leete |
|---|---|
| Next by Date: | Re: [PATCH] ipv4 skbuff locking scope, Albert D. Cahalan |
| Previous by Thread: | Re: [PATCH] ipv4 skbuff locking scope, Tom Leete |
| Next by Thread: | Re: [PATCH] ipv4 skbuff locking scope, Albert D. Cahalan |
| Indexes: | [Date] [Thread] [Top] [All Lists] |