On Fri, 3 Sep 2004 08:03:44 +1000
Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
> 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?
I have no problems with this.
> 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.