deps: enable OpenSSL asm support for riscv64#62606
deps: enable OpenSSL asm support for riscv64#62606JamieMagee wants to merge 1 commit intonodejs:mainfrom
Conversation
|
Review requested:
|
nodejs-github-bot
added
dependencies
|
Have just spent a lot of today trying to unbreak my cross-compile environment but it's now working again. Will do some tests with this (natively and with the cross-compile) and see how it goes but this will be great if we can enable the assembly stuff now. |
|
I encountered a strange OpenSSL compilation problem where it appears that the build system incorrectly fall-backs to x86_64 asm for a native riscv64 build: https://github.com/riscv-forks/node-riscv/actions/runs/24225505014/job/70735319923 I will give this PR a try in my new experimental CI system for riscv64: riscv-forks/node-riscv#1 |
FYI I initially hit that as well when I hadn't included the |
Yeah, that might be expected in a cross-compilation setup. But I find it surprising because I am compiling natively on riscv64. |
|
note: #62629 just landed with OpenSSL update to 3.5.6 |
Interesting - my native build (clang21 with |
JamieMagee
force-pushed
the
riscv64-openssl-asm
branch
from
428839b to
3359202
Compare
Rebased on top of |
JamieMagee
force-pushed
the
riscv64-openssl-asm
branch
from
3359202 to
9ad173a
Compare
There was a problem hiding this comment.
Could you also update the GN build recipe to add linux64-riscv64 ?
node/deps/openssl/unofficial.gni
Lines 105 to 115 in a6e8368
I am preparing patches to enable GN built Node.js for riscv64 and this would be necessary.
JamieMagee
force-pushed
the
riscv64-openssl-asm
branch
from
9ad173a to
5ea800d
Compare
|
@kxxt Done, added |
kxxt
left a comment
kxxt
left a comment
There was a problem hiding this comment.
Do we also need to update the following files?
node/deps/openssl/config/include_asm.h.tmpl
Lines 6 to 44 in 7e5e60b
node/deps/openssl/config/include_no-asm.h.tmpl
Lines 6 to 18 in 7e5e60b
sxa
left a comment
sxa
left a comment
There was a problem hiding this comment.
Hmmm I've built with this and if I've tested correctly it doesn't seem to show an improvement on the https tests (run without autocannon). I'd have hoped it would improve that a bit (as it does on x64).
I might also try and compare with a version using the system openssl on my boards to see if that shows any difference but do you have any tests where the results are noticeable?
Move linux64-riscv64 from NO_ASM_ARCHS to ASM_ARCHS in the OpenSSL config Makefile and regenerate the configuration. This adds asm/ and asm_avx2/ config variants alongside the existing no-asm/ variant. When riscv64 was first added to the OpenSSL config in 2021 (nodejs#40063), OpenSSL had no RISC-V assembly support. OpenSSL 3.5.x now ships 17 perlasm generators covering AES (zvkned, zvkb, zkn), SHA-256/512 (zvknha, zvknhb), GHASH/GCM (zvkg, zvbc), ChaCha (v, zbb), SM3 (zvksh), SM4 (zvksed), and CPUID detection. Runtime capability detection via riscvcap.c and the Linux hwprobe syscall ensures safe fallback to generic C code on hardware without these extensions. Also add riscv64 entries to the six asm gypi selector files: openssl_asm.gypi, openssl_asm_avx2.gypi, openssl-cl_asm.gypi, openssl-cl_asm_avx2.gypi, openssl-fips_asm.gypi, and openssl-fips_asm_avx2.gypi. Refs: nodejs/build#4099 Signed-off-by: Jamie Magee <jamie.magee@gmail.com>
JamieMagee
force-pushed
the
riscv64-openssl-asm
branch
from
5ea800d to
77a251a
Compare
@kxxt Yes, they did need updating. Added
@sxa The asm codepaths for riscv64 in OpenSSL 3.5 are mostly scalar optimizations and AES/SHA intrinsics. The gains are probably more modest than x86 where you get AVX/AES-NI. If you're seeing no difference on HTTPS benchmarks specifically, it might be worth checking |
kxxt
left a comment
kxxt
left a comment
There was a problem hiding this comment.
LGTM. But my approval doesn't count here, I think.
Trying with |
|
@sxa Thanks for running this. I dug a little bit more into what OpenSSL 3.5.6 actually ships, and what the hardware requirements are. 3.5.6 has no scalar SHA asm for RISC-V at all. The only file is Same on the asymmetric side: no BN-mont, no ECDSA-P256 in 3.5.6. BN-mont (openssl/openssl#28012) and SM2 (openssl/openssl#25918) are both 3.6. So the TLS handshake is unaffected by this PR regardless of hardware. What's actually live on rv64gc is the generic 4-table AES asm (your 16% on aes-256-cbc), plus the V+Zbb ChaCha20 path if your hardware exposes it. The Zvkned AES, fused AES-GCM, and vector SHA paths all need the vector crypto extensions, which I don't think any shipping silicon has. So for TLS 1.3 on rv64gc with this PR: the bulk cipher gets the AES-CBC boost on its AES portion, GHASH stays in C (no Zbc on rv64gc), SHA stays in C, handshake stays in C. A full HTTPS run on this hardware is dominated by paths the PR can't reach in 3.5.6. The next OpenSSL bump should change that. BN-mont alone usually moves RSA handshake numbers by 5–10% on similar work for other arches, and the Zbb scalar SHA-256 lands at the same time. |
Thanks that makes sense - the board I was primarily testing on (SpacemiT-K1) has the V extension with a suitable length but not the crypto vector bits. I guess we'll see if we get boost with the next openssl bump. I did try a quick test by building a standalone openssl 3.5 vs 3.6 and it only seemed to show a 2% boost for |
6 participants
When riscv64 was added to the OpenSSL config in 2021 (#40063), OpenSSL had no RISC-V assembly at all, so it went into
NO_ASM_ARCHS. OpenSSL 3.5.x now has perlasm generators for AES, SHA-256/512, GHASH/GCM, ChaCha, SM3, SM4, and CPUID. All with runtime extension detection viariscvcap.cand the Linuxhwprobesyscall, so there's no risk on hardware without the crypto extensions.This moves linux64-riscv64 from
NO_ASM_ARCHStoASM_ARCHSin deps/openssl/config/Makefile, regenerates the config (addingasm/andasm_avx2/variants with 16 generated assembly files each), and adds riscv64 entries to the six gypi selector files.Generated with
nix shell nixpkgs#nasm -c make linux64-riscv64in deps/openssl/config/.Refs: nodejs/build#4099