Messages in this thread | | | Date | Wed, 26 May 1999 17:09:49 +0200 | From | Artur Skawina <> | Subject | Re: 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/
| |