| To: | Matt Mackall <mpm@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: serious netpoll bug w/NAPI |
| From: | "David S. Miller" <davem@xxxxxxxxxxxxx> |
| Date: | Wed, 16 Feb 2005 15:54:07 -0800 |
| Cc: | jmoyer@xxxxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <20050216234406.GA3120@xxxxxxxxx> |
| References: | <20050208201634.03074349.davem@xxxxxxxxxxxxx> <20050209183219.GA2366@xxxxxxxxx> <20050209164658.409f8950.davem@xxxxxxxxxxxxx> <20050210011104.GF2366@xxxxxxxxx> <16914.31886.665975.522710@xxxxxxxxxxxxxxxxxxxxxxxxxx> <20050216050722.GC3358@xxxxxxxxx> <20050216150236.61ca5faf.davem@xxxxxxxxxxxxx> <20050216234406.GA3120@xxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
On Wed, 16 Feb 2005 15:44:06 -0800 Matt Mackall <mpm@xxxxxxxxxxx> wrote: > Ok. We've got a few cases: > > 1) recursion on cpu1 If you hit this case, and therefore can't re-enter into ->poll(), you must drop the packet or so something else if netif_queue_stopped() since netpoll has no means by which to cause the TX queue to make forward progress. Do you at least agree with this? Perhaps you can create a "pending netpoll() packet" queue so that you don't have to drop the SKB in this case. Make the queue get processed via softint processing. I think this will work. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: serious netpoll bug w/NAPI, Matt Mackall |
|---|---|
| Next by Date: | Re: serious netpoll bug w/NAPI, Matt Mackall |
| Previous by Thread: | Re: serious netpoll bug w/NAPI, Matt Mackall |
| Next by Thread: | Re: serious netpoll bug w/NAPI, Matt Mackall |
| Indexes: | [Date] [Thread] [Top] [All Lists] |