| To: | hadi@xxxxxxxxxx |
|---|---|
| Subject: | Re: netif_rx packet dumping |
| From: | "David S. Miller" <davem@xxxxxxxxxxxxx> |
| Date: | Thu, 3 Mar 2005 13:32:37 -0800 |
| Cc: | shemminger@xxxxxxxx, rhee@xxxxxxxxxxxx, jheffner@xxxxxxx, Yee-Ting.Li@xxxxxxx, baruch@xxxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <1109885065.1098.285.camel@jzny.localdomain> |
| References: | <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
On 03 Mar 2005 16:24:25 -0500 jamal <hadi@xxxxxxxxxx> wrote: > Ok, this does sound more reasonable. Out of curiosity, are packets being > dropped at the socket queue? Why is "dump till empty" behaviour screwing > over TCP. Because it does the same thing tail-drop in routers do. It makes everything back off a lot and go into slow start. If we'd just drop 1 packet per flow or something like that (so it could be fixed with a quick fast retransmit), TCP would avoid regressing into slow start. You say "use a NAPI driver", but netif_rx() _IS_ a NAPI driver. process_backlog() adheres to quotas and every other stabilizing effect NAPI drivers use, the only missing part is the RX interrupt disabling. We should eliminate the max backlog thing completely. There is no need for it. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 7/7] netpoll: avoid kfree_skb on packets with destructo, Matt Mackall |
|---|---|
| Next by Date: | Re: [PATCH 7/7] netpoll: avoid kfree_skb on packets with destructo, Jeff Garzik |
| Previous by Thread: | Re: netif_rx packet dumping, jamal |
| Next by Thread: | Re: netif_rx packet dumping, Stephen Hemminger |
| Indexes: | [Date] [Thread] [Top] [All Lists] |