> + ROUND1(-128) ROUND(-124) ROUND(-120) ROUND(-116)
> + ROUND (-112) ROUND(-108) ROUND(-104) ROUND(-100)
> + ROUND (-96) ROUND(-92) ROUND(-88) ROUND(-84)
> + ROUND (-80) ROUND(-76) ROUND(-72) ROUND(-68)
> + ROUND (-64) ROUND(-60) ROUND(-56) ROUND(-52)
> ROUND (-48) ROUND(-44) ROUND(-40) ROUND(-36)
> ROUND (-32) ROUND(-28) ROUND(-24) ROUND(-20)
> ROUND (-16) ROUND(-12) ROUND(-8) ROUND(-4)
i've played with 128 byte chunks too, and the original author (Finn Arne
Gangstad) did of course explore this possibility as well. Just think about
it, smaller chunks are rather common. The performance difference between
64-byte and 128-byte chunks is mostly only visible if everything is fully
cached (like in your benchmark). In cold-cache situations it's invisible.
The hot-cache benchmark is rather misleading, because according to that
benchmark the fastest routine is that is unrolled to handle a whole MTU
sized packet. Going from 64 bytes to 128 bytes causes 192 bytes more
icache footprint, i dont think this is worth it. Your boundary condition
bugfix looks like a correct fix though.
doing fast MMX TCP checksums is possible, even if the MMX engine doesnt
have a carry logic, this is from a csum routine i wrote a year ago:
movq %%mm1, %%mm3;
paddd (%%esi),%%mm1;
pcmpgtd %%mm1, %%mm3;
psubd %%mm3, %%mm1;
movq %%mm1, %%mm3;
paddd 8(%%esi),%%mm1;
pcmpgtd %%mm1, %%mm3;
psubd %%mm3, %%mm1;
movq %%mm1, %%mm3;
paddd 16(%%esi),%%mm1;
pcmpgtd %%mm1, %%mm3;
psubd %%mm3, %%mm1;
[...etc.]
this does perform about 10-30% faster than the 'normal' routines (i think
i found an even faster version than the above, but you the above one
demonstrates the method nicely), but i finally found that the FPU handling
complexity is simply not worth it. More and more networking cards are
doing IP checksumming anyway.
-- mingo
-
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/