lkml.org 
[lkml]   [1999]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ia32 ip checksum optimizations
Andrea Arcangeli wrote:
>
> On Wed, 26 May 1999, Artur Skawina wrote:
>
> >It does test for 32bit aligment - this routine can not be called
> >with buf&1, so it's enough to just check this bit.
>
> Where is enforced that such routine is never called with buf&1? Just to
> produce an example: changing kmalloc internals will allow csum_partial to
> break. Also changing the define of MAX_HEADER for a new protocol would
> break the csum.

be serious.

(1) the checksum is defined in terms of 16bit words - it might have
some 'wonderful properties', but being able to directly compute it
from half of every word isn't one of them :)
(2) if kmalloc starts returning unaligned blocks we're in trouble
anyway
(3) it's the IP checksum

Unless you start checksumming with an odd address [1], buf&1==0.

[1] and this can't happen unless either (a) mem allocation routines
start returning unaligned memory, or (b) you keep partial buffers
stored at odd addresses.


> I instead assume that %esi is 32bit aligned _only_ to optimize the
> routine. My csum will be slower if %esi is not aligned but it won't break.

"benchmark, don't speculate" [1]

[1] I did. And, other than for almost fullsized mtu lengths [2], your
'optimization' appears to slow things down, esp. for mixed lens,
roughly resemling real usage. The differences are small, and
could have been influenced by noise, but I've never seen your
routine do better...

[2] which can be done a lot faster anyway, but with an significatly
increased cache footprint (iirc, 32x -> 32xx bytes), and
therefore may not be worth it for the general case


> >the <686 csum_partial_copy_generic already does align the destination.
>
> Where?? The only time %edi is changed is after every unrolled loop where
> is incremented of 64 bytes.

look again


> >Now, with the alignment issue behind, how about concentrating
>
> Do I convinced you that we shouldn't rely on the %esi 16bit alignement?

of course, not. [1]

[1] and btw this assumption (buf%1==0) is present in almost every
architecture. I didn't look if they used similar tricks to avoid
the branches though :)


> such way to get some more bit of performances (to break that you should
> change the alignment of pages in memory and not only develop some
> different thing in the network side or change kmalloc, and considering
> it's 686 specific stuff I guess it won't ever break :-).



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.055 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site