The current design pattern for choosing CRC32 implementations has not scaled well to four architectures (x86, arm64, ppc64le, s390x).
- The code to choose the implementation at compile time is fragile, and confusing.
- It is difficult to understand why arm64 maps to X86_HOST since this label does not reflect that it also has a software implementation.
Here is the current list of files:
src/checksum/power8/crc32.S POWERPC_HOST src/checksum/power8/crc32_wrapper.c POWERPC_HOST src/checksum/x86/checksum.c X86_HOST src/checksum/zseries/crc32-s390x.c ZSERIES_HOST src/checksum/zseries/crc32le-vx.S ZSERIES_HOST
One proposal is to refactor based on features + architecture instead of just architecture:
src/checksum/power8/crc32.S POWERPC_CRC32 src/checksum/power8/crc32_wrapper.c POWERPC_CRC32 src/checksum/sw/checksum.c SOFTWARE_CRC32 src/checksum/x86/checksum.c X86_CRC32 src/checksum/zseries/crc32-s390x.c ZSERIES_CRC32 src/checksum/zseries/crc32le-vx.S ZSERIES_CRC32
In this scenario, the newer architectures (ppc64 and s390x) which only use hardware implementations, can continue to only use their respective hardware implementations. ARM64 can simply use the software version. On x86, both X86_CRC32 and SOFTWARE_CRC32 would be enabled since not all x86 machines have SSE 4.1.
- is related to
-
SERVER-25853 SLES 11 kernel does not support s390x vx instructions
-
- Closed
-
-
WT-2882 Create CRC32 Hardware implementation for ARM8
-
- Closed
-
- links to