On 03 Mar 2005 17:26:51 -0500
jamal <hadi@xxxxxxxxxx> wrote:
> On Thu, 2005-03-03 at 17:02, John Heffner wrote:
> > On Thu, 3 Mar 2005, Stephen Hemminger wrote:
> > > 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
> > control.
>
> recall this is a queue that is potentially shared by many many flows
> from potentially many many interfaces i.e it deals with many many
> micro-scale bursts.
> Clearly, the best approach is to have lots and lots of memmory and to
> make that queue real huge so it can cope with all of them all the time.
> We dont have that luxury - If you restrict the queue size, you will have
> to drop packets... Which ones?
> Probably simplest solution is to leave it as is right now and just
> adjust the contraints based on your system memmory etc.
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.
|