netdev
[Top] [All Lists]

Re: [RFC/PATCH] "strict" ipv4 reassembly

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Thomas Graf <tgraf@xxxxxxx>
Date: Wed, 18 May 2005 03:37:12 +0200
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, akepner@xxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20050518011632.GA27813@gondor.apana.org.au>
References: <20050517.104947.112621738.davem@davemloft.net> <E1DYAHF-0006qW-00@gondolin.me.apana.org.au> <20050518004733.GG13748@postel.suug.ch> <20050518011632.GA27813@gondor.apana.org.au>
Sender: netdev-bounce@xxxxxxxxxxx
* Herbert Xu <20050518011632.GA27813@xxxxxxxxxxxxxxxxxxx> 2005-05-18 11:16
> On Wed, May 18, 2005 at 02:47:33AM +0200, Thomas Graf wrote:
> > 
> > I like this, although the problem is derived to the definition
> > of the threshold. Any ideas on how to define this? A
> 
> The threshold doesn't need to be very large at all since it is
> essentially the maximum reordering distance that we allow.
> 
> However, for an initial estimate we can be conservative and
> use something like 30000.  If we're too conservative the SGI
> guys will tell us :)

OK, I initially thought you would head for a much larger
threshold. Not sure if 30000 is large enough for a full
scale NFS server though ;-> You conviced me that my idea
doesn't have any real advantage over yours, it essentialy
gets down the same result but yours is probably easier to
implement and we can also adopt the threshold dynamicaly
depending on the type of system. A big advantage is surely
that it is quite easy to tune this parameter for certain
more difficult cases.

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