[Top] [All Lists]

Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment

To: "David S. Miller" <davem@xxxxxxxxxx>
Subject: Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Fri, 3 Sep 2004 08:03:44 +1000
Cc: Patrick McHardy <kaber@xxxxxxxxx>, yoshfuji@xxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20040902144436.2c8c1337.davem@xxxxxxxxxx>
References: <4137681D.3000902@xxxxxxxxx> <20040902144436.2c8c1337.davem@xxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040722i
On Thu, Sep 02, 2004 at 02:44:36PM -0700, David S. Miller wrote:
> I see only one remaining possible improvement.  If the fraggap
> area is paged data, we probably should try use page frags
> in the new SKB if this split occurs in ip_append_page().

Yes.  That could also tie into another optimisation.  But it's
an ugly one :) The sk->csum values are added up at the end of
the processing so when we move bytes to and fro the total csum
value stays the same even if the fragment csum values change.

Therefore we can get rid of the csum adjustments except for the
parity bit in the getfrag call.

Is this an acceptable optimisation to you guys?

Another thing we can do is to not always fill up the frags in the middle
and then move bytes off them.  As it is if you do a send that spans
multiple packets each fragment will be filled up to the full and then
chopped off when the next one is started.

And to finish it off, here is a really trivial patch to shave off 27
bytes from the source code :) It does nothing else, well unless your
compiler decides to compile csum_block_sub out-of-line.

Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>

Visit Openswan at
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page:
PGP Key:

Attachment: p
Description: Text document

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