| To: | Stephen Hemminger <shemminger@xxxxxxxx> |
|---|---|
| Subject: | Re: [RFT] netif_queue_stopped in TBF scheduler |
| From: | "David S. Miller" <davem@xxxxxxxxxx> |
| Date: | Fri, 18 Jun 2004 13:51:39 -0700 |
| Cc: | netdev@xxxxxxxxxxx, lartc@xxxxxxxxxxxxxxx |
| In-reply-to: | <20040617160930.729b35ad@dell_ss3.pdx.osdl.net> |
| References: | <58D550446979A646A05649BF9EAF113AA2E995@orsmsx407> <20040617155603.0651081c@dell_ss3.pdx.osdl.net> <20040617160930.729b35ad@dell_ss3.pdx.osdl.net> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
On Thu, 17 Jun 2004 16:09:30 -0700 Stephen Hemminger <shemminger@xxxxxxxx> wrote: > There is a race between the device and scheduler if the scheduler looks > at netif_queue_stopped. What can happen is that the device decides it is > ready, > just after the stopped check, and the scheduler decides it is throttled. > > The simple way is to just have the scheduler always dequeue and leave the flow > control up to the driver and the core scheduling loop. CBQ, HFSC, etc. etc. have this same logic too. I agree, the flow control should be handled at the top level by qdisc_restart(), and it does by invoking ->requeue() if the xmit fails at the device level or it cannot obtain the necessary locks. I'm going to make this fix across the board. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [margitsw@t-online.de: Re: 2.6.7], Luis R. Rodriguez |
|---|---|
| Next by Date: | Re: [PATCH] (4/4) add loss option to network delay scheduler, David S. Miller |
| Previous by Thread: | [RFT] netif_queue_stopped in TBF scheduler, Stephen Hemminger |
| Next by Thread: | [PATCH] Add /proc/net/tcp_listen, Andi Kleen |
| Indexes: | [Date] [Thread] [Top] [All Lists] |