netdev
[Top] [All Lists]

Re: netif_rx packet dumping

To: John Heffner <jheffner@xxxxxxx>
Subject: Re: netif_rx packet dumping
From: Lennert Buytenhek <buytenh@xxxxxxxxxxxxxx>
Date: Fri, 4 Mar 2005 02:42:27 +0100
Cc: Stephen Hemminger <shemminger@xxxxxxxx>, hadi@xxxxxxxxxx, "David S. Miller" <davem@xxxxxxxxxxxxx>, rhee@xxxxxxxxxxxx, Yee-Ting.Li@xxxxxxx, baruch@xxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <Pine.LNX.4.58.0503031818270.22311@xxxxxxxxxxxxx>
References: <20050303125556.6850cfe5.davem@xxxxxxxxxxxxx> <1109884688.1090.282.camel@xxxxxxxxxxxxxxxx> <20050303132143.7eef517c@xxxxxxxxxxxxxxxxx> <1109885065.1098.285.camel@xxxxxxxxxxxxxxxx> <20050303133237.5d64578f.davem@xxxxxxxxxxxxx> <20050303135416.0d6e7708@xxxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0503031657300.22311@xxxxxxxxxxxxx> <1109888811.1092.352.camel@xxxxxxxxxxxxxxxx> <20050303151606.3587394f@xxxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0503031818270.22311@xxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Thu, Mar 03, 2005 at 06:48:50PM -0500, John Heffner wrote:

> > Another alternative would be some form of adaptive threshold,
> > something like adaptive drop tail described in this paper.
> > http://www.ee.cityu.edu.hk/~gchen/pdf/ITC18.pdf
> >
> > Since netif_rx is running at interrupt time, it has to be simple/quick.
> 
> All these AQM schemes are trying to solve a fundamentally different
> problem.  With TCP at least, the only congestion experienced at this point
> will be transient, so you do not want to send any congestion signals (drop
> packets) if you can avoid it at all.  Making the limit as high as you can
> tolerate seems like the best thing to me.

If the traffic does not terminate locally (f.e. when doing routing),
an insanely large queue has more disadvantages than advantages.

If you're routing those exact same TCP packets on the way to their
final destination, you run the risk of not sending out any congestion
signals in the cases where you should, making your forwarding latency
skyrocket (punishing all the other flows) in the process.


--L

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