[Top] [All Lists]

Re: netif_rx packet dumping

To: Stephen Hemminger <shemminger@xxxxxxxx>
Subject: Re: netif_rx packet dumping
From: John Heffner <jheffner@xxxxxxx>
Date: Thu, 3 Mar 2005 17:02:39 -0500 (EST)
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, hadi@xxxxxxxxxx, rhee@xxxxxxxxxxxx, Yee-Ting.Li@xxxxxxx, baruch@xxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20050303135416.0d6e7708@xxxxxxxxxxxxxxxxx>
References: <20050303123811.4d934249@xxxxxxxxxxxxxxxxx> <20050303125556.6850cfe5.davem@xxxxxxxxxxxxx> <1109884688.1090.282.camel@xxxxxxxxxxxxxxxx> <20050303132143.7eef517c@xxxxxxxxxxxxxxxxx> <1109885065.1098.285.camel@xxxxxxxxxxxxxxxx> <20050303133237.5d64578f.davem@xxxxxxxxxxxxx> <20050303135416.0d6e7708@xxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Thu, 3 Mar 2005, Stephen Hemminger wrote:

> On Thu, 3 Mar 2005 13:32:37 -0800
> "David S. Miller" <davem@xxxxxxxxxxxxx> wrote:
> > 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.
> Maybe a simple Random Exponential Drop (RED) would be more friendly.

That would probably not be appropriate.  This queue is only for absorbing
micro-scale bursts.  It should not hold any data in steady state like a
router queue can.  The receive window can handle the macro scale flow


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