Date: Fri, 25 Jul 2008 02:58:01 -0700 (PDT)
Message-Id: <20080725.025801.229691344.davem@davemloft.net>
To: herbert@gondor.apana.org.au
Cc: pupilla@hotmail.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: ipsec: ipcomp - Decompress into frags if necessary
From: David Miller <davem@davemloft.net>
In-Reply-To: <20080725074328.GB16747@gondor.apana.org.au>
References: <E1KM0Wl-0001zC-00@gondolin.me.apana.org.au>
	<20080725074109.GA16747@gondor.apana.org.au>
	<20080725074328.GB16747@gondor.apana.org.au>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1227
Lines: 34

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 25 Jul 2008 15:43:28 +0800

> On Fri, Jul 25, 2008 at 03:41:09PM +0800, Herbert Xu wrote:
> >
> > Here is the first part:
> 
> And finally:
> 
> ipsec: ipcomp - Decompress into frags if necessary
> 
> When decompressing extremely large packets allocating them through
> kmalloc is prone to failure.  Therefore it's better to use page
> frags instead.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Also applied, nice work Herbert.

About MAX_SKB_FRAGS, if we go over that limit we probably need to
log a message or something because we'll likely get that same kind
of huge sized packet that we can't handle in future retransmits.
There is no way to figure out that this is what is happening.

Actually I wonder if it's even possible.  Our limit is 64K anyways
(and that's our scratch buffer size) and MAX_SKB_FRAGS is always
large enough to accomodate at least 64K of data.

So perhaps it wants a WARN_ON :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/