netdev
[Top] [All Lists]

Re: netif_rx packet dumping

To: Stephen Hemminger <shemminger@xxxxxxxx>
Subject: Re: netif_rx packet dumping
From: Baruch Even <baruch@xxxxxxxxx>
Date: Thu, 03 Mar 2005 21:26:58 +0000
Cc: Injong Rhee <rhee@xxxxxxxxxxxx>, John Heffner <jheffner@xxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, Yee-Ting Li <Yee-Ting.Li@xxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <20050303123811.4d934249@dxpl.pdx.osdl.net>
References: <20050303123811.4d934249@dxpl.pdx.osdl.net>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Debian Thunderbird 1.0 (X11/20050116)
Stephen Hemminger wrote:
Both BIC TCP 1.1 and TCP-H include patches to disable the queue
throttling behaviour of netif_rx. 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.


My question is why did BIC TCP and TCP-H turn off the throttling?
Was it because they were/are using older 2.4 devices without NAPI.

NAPI was not used because it caused skews in the performance, I haven't tested it myself, just passing hearsay.


I have patches for the SACK processing to improve performance which should reduce the problems with the queues, but they are for 2.6.6 and forward porting them to 2.6.11 is quite a bit of work (too much was changed in conflicting areas). I hope to get to work on this soon.

The bad effect of the queue throttling was mostly the killed ack clock and the fact that recovery was only when timeout happened. Preferably only the packets that don't fit should be dropped, but the queue emptying should not be waited for.

Baruch

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