From: Daniel Borkmann > > Which architecture and which version of crc32_le() does your kernel use? > > It's using slice-by-8 algorithm, and my machine is [only] > a core i7 (x86_64). Apparently, it is not using the crypto > version that is accelerated. I still can't imagine it being that slow. The sctp code isn't known for its fast paths, although these are per-message, not per byte I'd have thought they'd still be significant. Having looked at the code, try compiling with CRC_LE_BITS == 8. I suspect the much smaller data cache footprint will help, and the number of instructions won't be that many less (due to all the shifts). What may help is to have a 'double shift' table and compute the crc's of the odd and even bytes separately, then xor them together at the end. That might improve the dependency chains and let all the cpu execute more instructions in parallel. Another improvement is to read the next byte from the buffer before processing the previous one (possibly with a slight loop unroll). As has been noted elsewhere, using a 16 entry lookup table can be faster than the 256 entry one. What I don't know is whether the crc32 can be analysed down do a small number of shifts and xors (crc16 reduces quite nicely) that might easily execute faster than the lookup table. David -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
