Messages in this thread | | | Date | Mon, 24 May 1999 13:03:15 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: [patch] checksum P6 asm buffer overflow fix + 686 improvements |
| |
On Mon, 24 May 1999, Andrea Arcangeli wrote:
> + 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/
| |