crc: Add vector-accelerated assembly code for RISC-V 64-bit architecture with Zvbc instruction set by yinlenree · Pull Request #350 · intel/isa-l

yinlenree · 2025-07-23T12:23:19Z

I have implemented vector-accelerated CRC modules (including CRC16, CRC32, and CRC64) using the RISC-V V, Zbc and Zvbc instruction sets, with full functional verification and performance testing completed.

The implementation primarily leverages the vclmul.v and vclmulh.v (carry-less multiply) instructions for data folding. For big-endian processing, it additionally utilizes vrgather.vv instructions for byte-order reversal. The final checksum is computed via Barrett reduction.

pablodelara · 2025-07-25T09:06:54Z

Hi @yinlenree. I suggest you include commit title like
"crc: add RISC-V implementation" and then you can include your current commit message as the body.
@sunyuechi, can you review this PR? Thanks!

sunyuechi · 2025-07-25T09:20:20Z

I'll review it carefully next week. For now, I’ve noticed two issues:

If the compiler doesn't support those -march options, the newly added CRC files will still be compiled, leading to build failures.

Some files have trailing blank lines at the end，please remove all of them.

Some files have mixed indentation using both spaces and tabs. Please make them consistent. (You can see the differences using git diff.)

yinlenree · 2025-07-25T10:52:57Z

Understood, thank you both for the suggestions. I'll first address the compilation-related issues. This might take some time since I haven't worked on this aspect before.

sunyuechi · 2025-08-01T09:09:25Z

configure.ac

+				__asm__ volatile(
+					".option arch, +zbc\n"
+					"clmul zero, zero, zero\n"
+          "clmulh zero, zero, zero\n"


Please use either tabs or spaces consistently for indentation, and check other files as well.

sunyuechi · 2025-08-01T09:09:58Z

include/riscv64_multibinary.h

 #include <sys/auxv.h>
+#include <asm/hwprobe.h>  // 包含 RISC-V 硬件探测相关的宏定义（如 RISCV_HWPROBE_EXT_ZBB）
+#include <unistd.h>       // 提供系统调用相关声明
+#include <sys/syscall.h>  // 定义 __NR_riscv_hwprobe 系统调用号


Please use English comments, and check other files as well.

pablodelara · 2025-08-01T09:35:34Z

crc/riscv64/crc_riscv64_dispatcher.c

+DEFINE_INTERFACE_DISPATCHER(crc32_gzip_refl)
+{
+#if HAVE_RVV && HAVE_ZBC && HAVE_ZVBC && HAVE_ZVBB
+        struct riscv_hwprobe _probe = INIT_PROBE_STRUCT();


All these lines (from 131 to 135) are always the same throughout this file. Would be better to move it to a separate function.

I wrote a function to determine experimental extensions, while the logic for standard extensions remains unchanged. Do you think this is acceptable?
DEFINE_INTERFACE_DISPATCHER(crc16_t10dif)
{
#if HAVE_RVV && HAVE_ZBC && HAVE_ZVBC && HAVE_ZVBB
unsigned long auxval = getauxval(AT_HWCAP);
if (auxval & HWCAP_RV('V') && CHECK_RISCV_EXTENSIONS("ZVBC", "ZVBB", "ZBC")) {
return crc16_t10dif_vclmul;
}
#endif
return crc16_t10dif_base;
}

Looks tidier, yes

yinlenree · 2025-08-04T01:48:19Z

Understood. I will revise my code and comments according to the requirements. Thank you both for the review.

sunyuechi · 2025-08-06T11:50:27Z

include/riscv64_multibinary.h

+#define EXT_CODE(ext) ( \
+	strcmp(ext, "ZBC") == 0 ? 7 : \
+	strcmp(ext, "ZVBB") == 0 ? 17 : \
+	strcmp(ext, "ZVBC") == 0 ? 18 : -1)


Please use macros instead of these numbers, for example: RISCV_HWPROBE_EXT_ZBC, RISCV_HWPROBE_EXT_ZVBB, ...

sunyuechi · 2025-08-06T11:50:40Z

include/riscv64_multibinary.h

+static inline int check_riscv_extensions(const char **extensions, size_t count)
+{
+	struct riscv_hwprobe _probe = INIT_PROBE_STRUCT();
+	syscall(__NR_riscv_hwprobe, &_probe, 1, 0, NULL, 0);


It seems that using hwprobe requires checking the kernel version?

Okay, I will replace the numbers with macros. Additionally, regarding the extension check, I plan to use version 6.8 as the cutoff—versions below this will not utilize the ZVBC vector acceleration.

Considering that the linux/version.h file may change after a kernel upgrade, making it impossible to determine whether the current kernel supports RISC-V extension macros using the LINUX_VERSION_CODE macro, I plan to directly check whether these extension macros are defined to decide the code distribution. The code is as follows.

#if defined(RISCV_HWPROBE_EXT_ZBC) && defined(RISCV_HWPROBE_EXT_ZVBB) && defined(RISCV_HWPROBE_EXT_ZVBC) #define EXT_CODE(ext) ( \ strcmp(ext, "ZBC") == 0 ? RISCV_HWPROBE_EXT_ZBC : \ strcmp(ext, "ZVBB") == 0 ? RISCV_HWPROBE_EXT_ZVBB : \ strcmp(ext, "ZVBC") == 0 ? RISCV_HWPROBE_EXT_ZVBC : \ -1) #endif ... static inline int check_riscv_extensions(const char **extensions, size_t count) { #ifdef EXT_CODE struct riscv_hwprobe _probe = INIT_PROBE_STRUCT(); syscall(__NR_riscv_hwprobe, &_probe, 1, 0, NULL, 0); for (size_t i = 0; i < count; i++) { if (!(_probe.value & EXT_CODE(extensions[i]))) { return 0; } } return 1; #else return 0; #endif }

Do you think this is okay?

My understanding is that the detection works by checking whether asm/hwprobe.h exists in the kernel, since these files didn’t exist before.

I found that in the kernel code from versions 6.4 to 6.7, although there is an hwprobe.h file in the include/asm directory, it lacks macros for offsets of extensions like ZVBC, ZBC, etc. These macros were only defined after version 6.8.
Additionally, I noticed that the offset for the V standard extension was defined in version 6.5. Does this mean I also need to check the definition of the V extension offset?
I'm unsure whether there was an interface for detecting extensions like ZVBC in kernels from versions 6.4 to 6.7. I have little experience in this area. Do you have any suggestions?
Here's the URL for the hwprobe.h file in Linux kernel 6.7 from the official repository:
https://github.com/torvalds/linux/blob/v6.7/arch/riscv/include/asm/hwprobe.h
The macro definitions are located here.
https://github.com/torvalds/linux/blob/v6.7/arch/riscv/include/uapi/asm/hwprobe.h

Maybe we can directly detect this macro, similar to how DPDK introduced hwprobe, with a minimum requirement of kernel 6.8?
https://inbox.dpdk.org/dev/20240827153230.52880-2-daniel.gregory@bytedance.com/

Yes, the bitmasks for ZVBC and ZBC were defined starting from version 6.8. I plan to add detection macros for the hwprobe.h file during the compilation phase, as well as detection macros for the bitmasks of these three extensions: ZVBC, ZVBB, and ZBC.

sunyuechi · 2025-08-24T11:30:49Z

Please test what happens if the kernel does not have hwprobe support, for example, by changing asm/hwprobe.h to a non-existent file. Currently, this causes a build error.

yinlenree · 2025-08-28T02:12:37Z

@sunyuechi I forgot to add the conditional check before including the asm/hwprobe.h header file. I've now fixed it and optimized the code, replacing time-consuming instructions and removing the Zvbb extension.

pablodelara · 2025-09-10T09:26:52Z

Could you review this PR again, @sunyuechi? I am thinking of first merging the "prefetch" PR and then this PR (after they are reviewed, of course).

sunyuechi · 2025-09-10T15:34:01Z

@pablodelara Okay, I'll check it tomorrow.

sunyuechi · 2025-09-10T15:57:53Z

crc/riscv64/crc_common_vclmul.h

+#define vec_15        v15
+#define vec_16        v16
+#define vec_17        v17
+#define vec_18        v18


#define tmp_0 t0 #define tmp_1 t1 #define tmp_2 t2 #define tmp_3 t3 #define tmp_4 t4 #define tmp_5 t5 #define vec_0 v0 #define vec_1 v1 ... #define vec_10 v10 #define vec_11 v11 #define vec_12 v12

Please remove these #define statements that do not improve readability, these t and v registers are already sufficiently clear on their own.

sunyuechi · 2025-09-10T16:16:17Z

crc/riscv64/crc_common_vclmul.h

+#define len           a2
+
+// return
+#define crc_ret       a0


Okay, understood. I will remove these redundant and unused #define statements.

sunyuechi · 2025-09-11T08:04:30Z

crc/riscv64/crc16_t10dif_copy_vclmul.S

+    vxor.vv v0, v8, v3
+
+    addi sp, sp, -16
+    vse64.v v0, (sp)


t5 and t6 are unused and can be utilized to eliminate stack operations.

sunyuechi · 2025-09-11T08:04:57Z

crc/riscv64/crc16_t10dif_vclmul.S

+    vslideup.vi v8, v9, 1
+    vxor.vv v0, v8, v3
+
+    addi sp, sp, -16


t5 and t6 are unused and can be utilized to eliminate stack operations.

sunyuechi · 2025-09-11T08:05:24Z

crc/riscv64/crc32_refl_common_vclmul.h

+    addi t4, t4, 16
+    crc_fold_512b_to_128b
+
+    addi sp, sp, -16


Please use t6 to reduce stack operations (and also check other files as well).

sunyuechi · 2025-09-11T08:08:41Z

crc/riscv64/crc16_t10dif_vclmul.S

+    ret
+
+.crc_fold:
+    # Initialize vector registers


This comment seems to be describing the purpose of vset, but it feels a bit unclear. Could we adjust it slightly?

sunyuechi · 2025-09-11T08:10:27Z

crc/riscv64/crc16_t10dif_copy_vclmul.S

+    ret
+
+.crc_fold:
+    # Initialize vector registers


This comment seems to be describing the purpose of vset, but it feels a bit unclear. Could we adjust it slightly?

Okay, I will replace stack pointer (sp) operations with idle registers in all files and improve the readability of comments in the code.

sunyuechi · 2025-09-11T12:59:45Z

crc/riscv64/crc_riscv64_dispatcher.c

+{
+#if HAVE_RVV && HAVE_ZBC && HAVE_ZVBC
+        unsigned long auxval = getauxval(AT_HWCAP);
+        if (auxval & HWCAP_RV('V') && CHECK_RISCV_EXTENSIONS("ZVBC", "ZBC")) {


According to the RISC-V manual,

The Zvknhb and Zvbc Vector Crypto Extensions — and accordingly the composite extensions Zvkn and Zvks — require a Zve64x base, or application ("V") base Vector Extension.

Since the vector instructions you are using exist in both Zve64x and V, it seems that if Zvbc is detected, there’s no need to additionally check for the V extension. Please also review whether any changes are needed in the compilation part regarding this.

Got it. I will try to place the detection of Zvbc before that of the V extension, so as to omit the check for the V extension. Thank you.

yinlenree · 2025-09-12T08:58:00Z

I have retained the stack pointer operations when calling crc32_iscsi_refl_vclmul, which are used to save the call information.

sunyuechi · 2025-09-12T09:03:48Z

It seems that the check in the file crc_riscv64_dispatcher.c has not been updated.

yinlenree · 2025-09-12T09:42:00Z

It seems that the check in the file crc_riscv64_dispatcher.c has not been updated.

Sorry, I forgot about this. Now I have removed the HAVE_RVV macro from both the dispatcher and the assembly file.

sunyuechi · 2025-09-12T10:42:10Z

crc/riscv64/crc16_t10dif_copy_vclmul.S

+    .word 0x4ba80000, 0xc01f0000, 0xd7710000, 0x5cc60000, 0xf9ad0000, 0x721a0000, 0x65740000, 0xeec30000
+    .word 0xa4150000, 0x2fa20000, 0x38cc0000, 0xb37b0000, 0x16100000, 0x9da70000, 0x8ac90000, 0x017e0000
+    .word 0x1f650000, 0x94d20000, 0x83bc0000, 0x080b0000, 0xad600000, 0x26d70000, 0x31b90000, 0xba0e0000
+    .word 0xf0d80000, 0x7b6f0000, 0x6c010000, 0xe7b60000, 0x42dd0000, 0xc96a0000, 0xde040000, 0x55b30000


Can you extract a .h file like crc32/64?
(crc/riscv64/crc16_t10dif_vclmul.S and crc/riscv64/crc16_t10dif_copy_vclmul.S)
Since the data is completely identical, many parts of the crc_fold_loop calculation .. are also the same.

I did not create a .h header file for crc16_t10dif_copy because its procedural code involves memory copying compared to other algorithm implementations. I only extracted the data for the calculation. Do you think this is acceptable?

sunyuechi · 2025-09-12T10:44:41Z

crc/riscv64/crc_riscv64_dispatcher.c

+{
+#if HAVE_ZBC && HAVE_ZVBC
+        unsigned long auxval = getauxval(AT_HWCAP);
+        if (auxval & HWCAP_RV('V') && CHECK_RISCV_EXTENSIONS("ZVBC", "ZBC")) {


The runtime v check can also be removed.

sunyuechi · 2025-09-12T10:45:32Z

crc/riscv64/crc16_t10dif_vclmul.S

+
+.crc_table_loop:
+    lbu a4, 0(a1)
+    add a1, a1, 1


This may cause errors in certain environments. For immediates, please use the standard addi whenever possible (and please check other files as well).

Okay, I will check my code.

pablodelara · 2025-11-05T14:35:09Z

@sunyuechi could you review the PR again?

sunyuechi · 2025-11-07T12:40:57Z

As discussed earlier, I hope to provide clearer performance test results or performance-related explanations, similar to https://github.com/intel/isa-l/pull/299 or other performance optimization PRs. @pablodelara

pablodelara · 2025-11-24T15:23:11Z

@sunyuechi are those perf test results expected from @yinlenree?

sunyuechi · 2026-01-16T15:38:10Z

Hi, could you summarize what the major recent changes did?
Also, please refer to #381 and stop passing different -march values by default; otherwise, compiling C code may generate illegal instructions, which cannot be resolved at runtime.

pablodelara · 2026-01-19T12:38:47Z

I also recommend rebasing the PR against latest master.

yinlenree · 2026-01-20T01:23:51Z

OK, during this period, I optimized the single-vector folding approach in the main loop to a method using vector-plus-scalar folding, maximizing utilization of the execution units within the core. The performance test of "make perf" shows this method outperforms all previous implementations, and the performance data has already been sent to you via email. @sunyuechi
Subsequently, as mentioned in this issue, I removed the modifications related to -march in the configure.ac file and added .option directives to the assembly files in the crc/riscv64 and erasure_code/riscv64 directories.
And I am now rebasing the PR.

sunyuechi · 2026-01-25T10:57:19Z

configure.ac

+			AC_MSG_CHECKING([whether compiler supports RISC-V Extension (ZBB)])
+			AC_COMPILE_IFELSE(
+				[AC_LANG_PROGRAM([#include <asm/hwprobe.h>], [
+					int a = RISCV_HWPROBE_EXT_ZBC;


sunyuechi · 2026-01-25T10:59:04Z

configure.ac

+						".option arch, +v, +zvbc\n"
+						"vsetivli zero, 2, e64, m1, ta, ma\n"
+						"vclmul.vv v0, v0, v0\n"
+						"vclmulh.vv v0, v0, v0\n"


It’s sufficient to check either cmul or cmulh

sunyuechi · 2026-01-25T10:59:29Z

configure.ac

+						".option arch, +v, +zvbc\n"
+						"vsetivli zero, 2, e64, m1, ta, ma\n"
+						"vclmul.vv v0, v0, v0\n"
+						"vclmulh.vv v0, v0, v0\n"


It’s sufficient to check either vcmul or vcmulh

sunyuechi · 2026-01-25T11:02:31Z

include/riscv64_multibinary.h

 #else /* __ASSEMBLY__ */
 #include <sys/auxv.h>
+#if HAVE_HWPROBE_H
+#include <asm/hwprobe.h>


Newer versions of glibc use sys/hwprobe.h, so a similar approach should be used in the relevant places.

#if HAVE_SYS_HWPROBE_H #include <sys/hwprobe.h> #elif HAVE_ASM_HWPROBE_H #include <asm/hwprobe.h>

sunyuechi · 2026-01-25T11:04:16Z

include/riscv64_multibinary.h

+	check_riscv_extensions((const char*[]){ __VA_ARGS__ }, \
+							sizeof((const char*[]){ __VA_ARGS__ })/sizeof(const char*))
+#endif
+


The compile-time logic around hwprobe here is a bit odd. It might be better to wrap all hwprobe-related code together, with an outer check for hwprobe itself and inner checks for hwprobe macros such as ZBC, ZBB, and ZVBC, for example:

#if HAVE_SYS_HWPROBE_H || HAVE_ASM_HWPROBE_H #if zbc zbb ...

sunyuechi · 2026-01-25T11:14:21Z

crc/riscv64/crc16_t10dif_copy_vclmul.S

+
+    slli a0, a0, 32
+    la t4, .shuffle_data_mask
+    addi sp, sp, -120


According to the calling convention, it should be 16-byte aligned.

In the standard RISC-V calling convention, the stack grows downward and the stack pointer is always kept 16-byte aligned.

sunyuechi · 2026-01-25T11:26:01Z

crc/riscv64/crc16_t10dif_copy_vclmul.S

+    clmulh a5, a4, s1
+    clmulh ra, a4, s3
+    clmulh gp, a4, s5
+    clmulh tp, a4, s7


Using ra, gp, tp as temporary registers violates ABI conventions. Is this necessary? If so, comments should be added to explain this.

Got it. I've applied the changes as requested above.

pablodelara · 2026-01-29T16:15:00Z

configure.ac

+		fi
+		if test "x$sys_hwprobe_h" = "xyes"; then
+			AC_DEFINE([HAVE_SYS_HWPROBE_H], [1], [Define if sys/hwprobe.h exists])
+			AM_CONDITIONAL([HAVE_SYS_HWPROBE_H], [true])


CI is reporting an issue on x86: configure: error: conditional "HAVE_SYS_HWPROBE_H" was never defined.

Got it. I forgot the definition in configure.ac. I have updated the file accordingly.

pablodelara · 2026-02-02T14:16:45Z

@sunyuechi could you review this last revision? Thanks!

pablodelara · 2026-02-09T11:31:19Z

@sunyuechi sorry for pinging you again, but would be good to have this reviewed ASAP. Release date is end of this month and I would like new optimizations to be merged by the end of this week.

pablodelara · 2026-02-16T17:57:01Z

Last call for this PR to be integrated in v2.32, thanks. @sunyuechi can you review it please? Thanks!

sunyuechi · 2026-02-26T06:38:19Z

include/riscv64_multibinary.h

+	static inline int check_riscv_extensions(const char **extensions, size_t count)
+	{
+		struct riscv_hwprobe _probe = INIT_PROBE_STRUCT();
+		syscall(__NR_riscv_hwprobe, &_probe, 1, 0, NULL, 0);


When sys/hwprobe.h is available: directly use the __riscv_hwprobe()

When only asm/hwprobe.h is available: define our own __riscv_hwprobe() wrapper function to encapsulate the syscall

The caller side uniformly uses __riscv_hwprobe()

sunyuechi · 2026-02-26T06:55:58Z

configure.ac

-			AM_CONDITIONAL([HAVE_RVV], [true]) rvv=yes],
-			[AC_DEFINE([HAVE_RVV], [0], [Disable RVV instructions])
-			AM_CONDITIONAL([HAVE_RVV], [false]) rvv=no]
+			AM_CONDITIONAL([HAVE_RVV], [true]) rvv=yes]


if the system doesn't have hwprobe, zvbc remains unset , which causes rvv=true to be set unconditionally.

Received, I have modified the code.

sunyuechi · 2026-02-27T13:38:33Z

configure.ac

+		else
+			AC_DEFINE([HAVE_ASM_HWPROBE_H], [0], [Define if asm/hwprobe.h not exists])
+			AM_CONDITIONAL([HAVE_ASM_HWPROBE_H], [false])
+		fi


We can remove the related if-else blocks, something like this:

AM_CONDITIONAL([HAVE_SYS_HWPROBE_H], [test "x$sys_hwprobe_h" = "xyes"]) AM_CONDITIONAL([HAVE_ASM_HWPROBE_H], [test "x$asm_hwprobe_h" = "xyes"]) AS_IF([test "x$sys_hwprobe_h" = "xyes"], [AC_DEFINE([HAVE_SYS_HWPROBE_H], [1], [Define if sys/hwprobe.h exists])]) AS_IF([test "x$asm_hwprobe_h" = "xyes"], [AC_DEFINE([HAVE_ASM_HWPROBE_H], [1], [Define if asm/hwprobe.h exists])])

sunyuechi · 2026-02-27T13:44:28Z

configure.ac

+				AM_CONDITIONAL([HAVE_ZBC], [true]) zbc=yes],
+				[AC_DEFINE([HAVE_ZBC], [0], [Disable ZBC instructions])
+				AM_CONDITIONAL([HAVE_ZBC], [false]) zbc=no]
+			)


use a macro, something like this:

AC_DEFUN([CHECK_RISCV_EXT], [ AC_MSG_CHECKING([whether compiler supports RISC-V Extension ($1)]) AC_COMPILE_IFELSE( [AC_LANG_PROGRAM([#include <asm/hwprobe.h>], [ int a = RISCV_HWPROBE_EXT_$1; __asm__ volatile( ".option arch, $2\n" $3 ); ])], [AC_DEFINE([HAVE_$1], [1], [Enable $1 instructions]) AM_CONDITIONAL([HAVE_$1], [true]) $4=yes], [AC_DEFINE([HAVE_$1], [0], [Disable $1 instructions]) AM_CONDITIONAL([HAVE_$1], [false]) $4=no] ) AC_MSG_RESULT([$$4]) ]) CHECK_RISCV_EXT([ZBC], [+zbc], ["clmul zero, zero, zero\n"], [zbc]) ...

sunyuechi · 2026-02-27T14:37:10Z

crc/riscv64/crc16_t10dif_copy_vclmul.S

+.option arch, +v, +zvbc, +zbc, +zbb
+.section .text
+.align 2
+.global crc16_t10dif_copy_vclmul


Missing .type and .size

sunyuechi · 2026-02-27T14:37:39Z

crc/riscv64/crc16_t10dif_vclmul.h

+
+    .text
+    .align  4
+    .set    .lanchor_crc_tab,. + 0


Many files use this kind of set — would it be better to replace them directly with labels?
.lanchor_crc_tab:

sunyuechi · 2026-02-27T14:38:27Z

crc/riscv64/crc32_gzip_refl_vclmul.h

+.equ    const_poly, 0x1db710641
+
+    .section .rodata
+    .text


Many files directly use the pattern, which causes .rodata to be overridden by .text, rendering it ineffective. All of these should be fixed:

Received, I have modified the code.

sunyuechi · 2026-02-28T11:07:47Z

LGTM. Thanks for the continued improvements.

sunyuechi · 2026-02-28T11:09:29Z

@pablodelara Hi, this looks good to go. Can we get it into 2.32?

pablodelara · 2026-03-02T09:00:29Z

@yinlenree @sunyuechi I am adding the following line in Release Notes:

Added new RVV CRC64/32/16 implementations.

pablodelara

One final comment. Check also other files that might be missing the .rodata section

pablodelara · 2026-03-02T12:34:53Z

crc/riscv64/crc16_t10dif_copy_vclmul.S

+    j .crc_table_loop_pre
+.size crc16_t10dif_copy_vclmul, . - crc16_t10dif_copy_vclmul
+
+.shuffle_data_mask = . + 0


This be in .rodata section instead of .text section

Okay, I have checked the other files, and it appears that only crc/riscv64/crc16_t10dif_copy_vclmul.S was missing the .rodata section. The code has been updated.

The CRC module of ISA-L has been accelerated using RISC-V's V, Zbc, Zbb and Zvbc, instruction sets, implementing data folding and Barrett reduction optimizations. Signed-off-by: Ji Dong <dong.ji1@zte.com.cn>

pablodelara · 2026-03-03T22:01:06Z

This is now merged, thanks!

yinlenree force-pushed the add-crc-riscv-vector-support branch from cd1a52d to 3259ef2 Compare July 24, 2025 03:36

yinlenree force-pushed the add-crc-riscv-vector-support branch 3 times, most recently from adef254 to 2379b73 Compare August 1, 2025 02:31

sunyuechi reviewed Aug 1, 2025

View reviewed changes

pablodelara reviewed Aug 1, 2025

View reviewed changes

yinlenree force-pushed the add-crc-riscv-vector-support branch from 2379b73 to 740d8a4 Compare August 6, 2025 07:18

sunyuechi reviewed Aug 6, 2025

View reviewed changes

yinlenree force-pushed the add-crc-riscv-vector-support branch from fe7ba9c to 0d79c34 Compare August 22, 2025 02:44

yinlenree force-pushed the add-crc-riscv-vector-support branch from 0d79c34 to ddd6706 Compare August 28, 2025 02:02

sunyuechi reviewed Sep 10, 2025

View reviewed changes

yinlenree force-pushed the add-crc-riscv-vector-support branch from ddd6706 to a2ee08c Compare September 11, 2025 06:59

sunyuechi reviewed Sep 11, 2025

View reviewed changes

yinlenree force-pushed the add-crc-riscv-vector-support branch from a2ee08c to ade80d5 Compare September 12, 2025 08:42

yinlenree force-pushed the add-crc-riscv-vector-support branch from ade80d5 to 56e655a Compare September 12, 2025 09:42

sunyuechi reviewed Sep 12, 2025

View reviewed changes

sunyuechi mentioned this pull request Sep 15, 2025

erasure_code: add prefetch and vsetvli optimization #351

Closed

yinlenree force-pushed the add-crc-riscv-vector-support branch from d42e43b to 5313ac9 Compare December 29, 2025 09:48

yinlenree force-pushed the add-crc-riscv-vector-support branch 2 times, most recently from d75406a to e674fbb Compare January 21, 2026 01:33

sunyuechi reviewed Jan 25, 2026

View reviewed changes

yinlenree force-pushed the add-crc-riscv-vector-support branch from e674fbb to 81dcddc Compare January 28, 2026 06:48

pablodelara reviewed Jan 29, 2026

View reviewed changes

yinlenree force-pushed the add-crc-riscv-vector-support branch from 81dcddc to aed015e Compare January 30, 2026 02:12

sunyuechi reviewed Feb 26, 2026

View reviewed changes

yinlenree force-pushed the add-crc-riscv-vector-support branch from aed015e to cdc4a71 Compare February 26, 2026 11:50

sunyuechi reviewed Feb 27, 2026

View reviewed changes

yinlenree force-pushed the add-crc-riscv-vector-support branch from cdc4a71 to 612fd0e Compare February 28, 2026 08:11

pablodelara reviewed Mar 2, 2026

View reviewed changes

crc: add RISC-V implementation

dc6d8f4

The CRC module of ISA-L has been accelerated using RISC-V's V, Zbc, Zbb and Zvbc, instruction sets, implementing data folding and Barrett reduction optimizations. Signed-off-by: Ji Dong <dong.ji1@zte.com.cn>

yinlenree force-pushed the add-crc-riscv-vector-support branch from 612fd0e to dc6d8f4 Compare March 3, 2026 01:19

pablodelara closed this Mar 3, 2026

Conversation

yinlenree commented Jul 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pablodelara commented Jul 25, 2025

Uh oh!

sunyuechi commented Jul 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yinlenree commented Jul 25, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yinlenree commented Aug 4, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sunyuechi commented Aug 24, 2025

Uh oh!

yinlenree commented Aug 28, 2025

Uh oh!

pablodelara commented Sep 10, 2025

Uh oh!

sunyuechi commented Sep 10, 2025

Uh oh!

sunyuechi Sep 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yinlenree commented Sep 12, 2025

Uh oh!

sunyuechi commented Sep 12, 2025

Uh oh!

yinlenree commented Sep 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

yinlenree commented Jul 23, 2025 •

edited

Loading

sunyuechi commented Jul 25, 2025 •

edited

Loading

sunyuechi Sep 10, 2025 •

edited

Loading