Description
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.
Attachments
Issue Links
- 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