[Top] [All Lists]

Re: netif_rx packet dumping

To: Stephen Hemminger <shemminger@xxxxxxxx>
Subject: Re: netif_rx packet dumping
From: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Thu, 3 Mar 2005 12:55:56 -0800
Cc: rhee@xxxxxxxxxxxx, jheffner@xxxxxxx, Yee-Ting.Li@xxxxxxx, baruch@xxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20050303123811.4d934249@xxxxxxxxxxxxxxxxx>
References: <20050303123811.4d934249@xxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Thu, 3 Mar 2005 12:38:11 -0800
Stephen Hemminger <shemminger@xxxxxxxx> wrote:

> The existing throttling algorithm causes all packets to be dumped
> (until queue emptys) when the packet backlog reaches
> netdev_max_backog. I suppose this is some kind of DoS prevention
> mechanism. The problem is that this dumping action creates mulitple
> packet loss that forces TCP back to slow start.
> But, all this is really moot for the case of any reasonably high speed
> device because of NAPI. netif_rx is not even used for any device that
> uses NAPI.  The NAPI code path uses net_receive_skb and the receive
> queue management is done by the receive scheduling (dev->quota) of the
> rx_scheduler.

Even without NAPI, netif_rx() ends up using the quota etc. machanisms
when the queue gets processed via process_backlog().

ksoftirqd should handle cpu starvation issues at a higher level.

I think it is therefore safe to remove the netif_max_backlog stuff
altogether.  "300" is such a non-sense setting, especially for gigabit
drivers which aren't using NAPI for whatever reason.  It's even low
for a system with 2 100Mbit devices.

<Prev in Thread] Current Thread [Next in Thread>