From: guoren@kernel.org
To: arnd@arndb.de, gregkh@linuxfoundation.org,
torvalds@linux-foundation.org, paul.walmsley@sifive.com,
palmer@dabbelt.com, anup@brainfault.org, atishp@atishpatra.org,
oleg@redhat.com, kees@kernel.org, tglx@linutronix.de,
will@kernel.org, mark.rutland@arm.com, brauner@kernel.org,
akpm@linux-foundation.org, rostedt@goodmis.org,
edumazet@google.com, unicorn_wang@outlook.com,
inochiama@outlook.com, gaohan@iscas.ac.cn, shihua@iscas.ac.cn,
jiawei@iscas.ac.cn, wuwei2016@iscas.ac.cn, drew@pdp7.com,
prabhakar.mahadev-lad.rj@bp.renesas.com, ctsai390@andestech.com,
wefu@redhat.com, kuba@kernel.org, pabeni@redhat.com,
josef@toxicpanda.com, dsterba@suse.com, mingo@redhat.com,
peterz@infradead.org, boqun.feng@gmail.com, guoren@kernel.org,
xiao.w.wang@intel.com, qingfang.deng@siflower.com.cn,
leobras@redhat.com, jszhang@kernel.org,
conor.dooley@microchip.com, samuel.holland@sifive.com,
yongxuan.wang@sifive.com, luxu.kernel@bytedance.com,
david@redhat.com, ruanjinjie@huawei.com, cuiyunhui@bytedance.com,
wangkefeng.wang@huawei.com, qiaozhe@iscas.ac.cn
Cc: ardb@kernel.org, ast@kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org, kvm@vger.kernel.org,
kvm-riscv@lists.infradead.org, linux-mm@kvack.org,
linux-crypto@vger.kernel.org, bpf@vger.kernel.org,
linux-input@vger.kernel.org, linux-perf-users@vger.kernel.org,
linux-serial@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-arch@vger.kernel.org, maple-tree@lists.infradead.org,
linux-trace-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-atm-general@lists.sourceforge.net,
linux-btrfs@vger.kernel.org, netfilter-devel@vger.kernel.org,
coreteam@netfilter.org, linux-nfs@vger.kernel.org,
linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org,
linux-media@vger.kernel.org
Subject: [RFC PATCH V3 05/43] rv64ilp32_abi: riscv: crc32: Utilize 64-bit width to improve the performance
Date: Tue, 25 Mar 2025 08:15:46 -0400 [thread overview]
Message-ID: <20250325121624.523258-6-guoren@kernel.org> (raw)
In-Reply-To: <20250325121624.523258-1-guoren@kernel.org>
From: "Guo Ren (Alibaba DAMO Academy)" <guoren@kernel.org>
The RV64ILP32 ABI, derived from a 64-bit ISA, uses 32-bit
BITS_PER_LONG. Therefore, crc32 algorithm could utilize 64-bit width
to improve the performance.
Signed-off-by: Guo Ren (Alibaba DAMO Academy) <guoren@kernel.org>
---
arch/riscv/lib/crc32-riscv.c | 35 ++++++++++++++++++-----------------
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/arch/riscv/lib/crc32-riscv.c b/arch/riscv/lib/crc32-riscv.c
index 53d56ab422c7..68dfb0565696 100644
--- a/arch/riscv/lib/crc32-riscv.c
+++ b/arch/riscv/lib/crc32-riscv.c
@@ -8,6 +8,7 @@
#include <asm/hwcap.h>
#include <asm/alternative-macros.h>
#include <asm/byteorder.h>
+#include <asm/csr.h>
#include <linux/types.h>
#include <linux/minmax.h>
@@ -59,12 +60,12 @@
*/
# define CRC32_POLY_QT_BE 0x04d101df481b4e5a
-static inline u64 crc32_le_prep(u32 crc, unsigned long const *ptr)
+static inline u64 crc32_le_prep(u32 crc, u64 const *ptr)
{
return (u64)crc ^ (__force u64)__cpu_to_le64(*ptr);
}
-static inline u32 crc32_le_zbc(unsigned long s, u32 poly, unsigned long poly_qt)
+static inline u32 crc32_le_zbc(u64 s, u32 poly, u64 poly_qt)
{
u32 crc;
@@ -85,7 +86,7 @@ static inline u32 crc32_le_zbc(unsigned long s, u32 poly, unsigned long poly_qt)
return crc;
}
-static inline u64 crc32_be_prep(u32 crc, unsigned long const *ptr)
+static inline u64 crc32_be_prep(u32 crc, u64 const *ptr)
{
return ((u64)crc << 32) ^ (__force u64)__cpu_to_be64(*ptr);
}
@@ -131,7 +132,7 @@ static inline u32 crc32_be_prep(u32 crc, unsigned long const *ptr)
# error "Unexpected __riscv_xlen"
#endif
-static inline u32 crc32_be_zbc(unsigned long s)
+static inline u32 crc32_be_zbc(xlen_t s)
{
u32 crc;
@@ -156,16 +157,16 @@ typedef u32 (*fallback)(u32 crc, unsigned char const *p, size_t len);
static inline u32 crc32_le_unaligned(u32 crc, unsigned char const *p,
size_t len, u32 poly,
- unsigned long poly_qt)
+ xlen_t poly_qt)
{
size_t bits = len * 8;
- unsigned long s = 0;
+ xlen_t s = 0;
u32 crc_low = 0;
for (int i = 0; i < len; i++)
- s = ((unsigned long)*p++ << (__riscv_xlen - 8)) | (s >> 8);
+ s = ((xlen_t)*p++ << (__riscv_xlen - 8)) | (s >> 8);
- s ^= (unsigned long)crc << (__riscv_xlen - bits);
+ s ^= (xlen_t)crc << (__riscv_xlen - bits);
if (__riscv_xlen == 32 || len < sizeof(u32))
crc_low = crc >> bits;
@@ -177,12 +178,12 @@ static inline u32 crc32_le_unaligned(u32 crc, unsigned char const *p,
static inline u32 __pure crc32_le_generic(u32 crc, unsigned char const *p,
size_t len, u32 poly,
- unsigned long poly_qt,
+ xlen_t poly_qt,
fallback crc_fb)
{
size_t offset, head_len, tail_len;
- unsigned long const *p_ul;
- unsigned long s;
+ xlen_t const *p_ul;
+ xlen_t s;
asm goto(ALTERNATIVE("j %l[legacy]", "nop", 0,
RISCV_ISA_EXT_ZBC, 1)
@@ -199,7 +200,7 @@ static inline u32 __pure crc32_le_generic(u32 crc, unsigned char const *p,
tail_len = len & OFFSET_MASK;
len = len >> STEP_ORDER;
- p_ul = (unsigned long const *)p;
+ p_ul = (xlen_t const *)p;
for (int i = 0; i < len; i++) {
s = crc32_le_prep(crc, p_ul);
@@ -236,7 +237,7 @@ static inline u32 crc32_be_unaligned(u32 crc, unsigned char const *p,
size_t len)
{
size_t bits = len * 8;
- unsigned long s = 0;
+ xlen_t s = 0;
u32 crc_low = 0;
s = 0;
@@ -247,7 +248,7 @@ static inline u32 crc32_be_unaligned(u32 crc, unsigned char const *p,
s ^= crc >> (32 - bits);
crc_low = crc << bits;
} else {
- s ^= (unsigned long)crc << (bits - 32);
+ s ^= (xlen_t)crc << (bits - 32);
}
crc = crc32_be_zbc(s);
@@ -259,8 +260,8 @@ static inline u32 crc32_be_unaligned(u32 crc, unsigned char const *p,
u32 __pure crc32_be_arch(u32 crc, const u8 *p, size_t len)
{
size_t offset, head_len, tail_len;
- unsigned long const *p_ul;
- unsigned long s;
+ xlen_t const *p_ul;
+ xlen_t s;
asm goto(ALTERNATIVE("j %l[legacy]", "nop", 0,
RISCV_ISA_EXT_ZBC, 1)
@@ -277,7 +278,7 @@ u32 __pure crc32_be_arch(u32 crc, const u8 *p, size_t len)
tail_len = len & OFFSET_MASK;
len = len >> STEP_ORDER;
- p_ul = (unsigned long const *)p;
+ p_ul = (xlen_t const *)p;
for (int i = 0; i < len; i++) {
s = crc32_be_prep(crc, p_ul);
--
2.40.1
next prev parent reply other threads:[~2025-03-25 12:18 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-25 12:15 [RFC PATCH V3 00/43] rv64ilp32_abi: Build CONFIG_64BIT kernel-self with ILP32 ABI guoren
2025-03-25 12:15 ` [RFC PATCH V3 01/43] rv64ilp32_abi: uapi: Reuse lp64 ABI interface guoren
2025-03-25 20:30 ` Jan Engelhardt
2025-03-26 3:35 ` Guo Ren
2025-03-25 20:41 ` Linus Torvalds
2025-03-26 6:34 ` Guo Ren
2025-03-27 16:20 ` Palmer Dabbelt
2025-03-25 12:15 ` [RFC PATCH V3 02/43] rv64ilp32_abi: riscv: Adapt Makefile and Kconfig guoren
2025-03-25 12:15 ` [RFC PATCH V3 03/43] rv64ilp32_abi: riscv: Adapt ULL & UL definition guoren
2025-03-25 12:15 ` [RFC PATCH V3 04/43] rv64ilp32_abi: riscv: Introduce xlen_t to adapt __riscv_xlen != BITS_PER_LONG guoren
2025-03-25 12:15 ` guoren [this message]
2025-03-25 12:15 ` [RFC PATCH V3 06/43] rv64ilp32_abi: riscv: csum: Utilize 64-bit width to improve the performance guoren
2025-03-25 12:15 ` [RFC PATCH V3 07/43] rv64ilp32_abi: riscv: arch_hweight: Adapt cpopw & cpop of zbb extension guoren
2025-03-25 12:15 ` [RFC PATCH V3 08/43] rv64ilp32_abi: riscv: bitops: Adapt ctzw & clzw " guoren
2025-03-25 12:15 ` [RFC PATCH V3 09/43] rv64ilp32_abi: riscv: Reuse LP64 SBI interface guoren
2025-03-25 12:15 ` [RFC PATCH V3 10/43] rv64ilp32_abi: riscv: Update SATP.MODE.ASID width guoren
2025-03-25 12:15 ` [RFC PATCH V3 11/43] rv64ilp32_abi: riscv: Introduce PTR_L and PTR_S guoren
2025-03-25 12:15 ` [RFC PATCH V3 12/43] rv64ilp32_abi: riscv: Introduce cmpxchg_double guoren
2025-03-25 12:15 ` [RFC PATCH V3 13/43] rv64ilp32_abi: riscv: Correct stackframe layout guoren
2025-03-25 12:15 ` [RFC PATCH V3 14/43] rv64ilp32_abi: riscv: Adapt kernel module code guoren
2025-03-25 12:15 ` [RFC PATCH V3 15/43] rv64ilp32_abi: riscv: mm: Adapt MMU_SV39 for 2GiB address space guoren
2025-03-25 12:15 ` [RFC PATCH V3 16/43] rv64ilp32_abi: riscv: Support physical addresses >= 0x80000000 guoren
2025-03-25 12:15 ` [RFC PATCH V3 17/43] rv64ilp32_abi: riscv: Adapt kasan memory layout guoren
2025-03-25 12:15 ` [RFC PATCH V3 18/43] rv64ilp32_abi: riscv: kvm: Initial support guoren
2025-03-25 12:16 ` [RFC PATCH V3 19/43] rv64ilp32_abi: irqchip: irq-riscv-intc: Use xlen_t instead of ulong guoren
2025-03-25 12:16 ` [RFC PATCH V3 20/43] rv64ilp32_abi: drivers/perf: Adapt xlen_t of sbiret guoren
2025-03-25 12:16 ` [RFC PATCH V3 21/43] rv64ilp32_abi: asm-generic: Add custom BITS_PER_LONG definition guoren
2025-03-25 12:16 ` [RFC PATCH V3 22/43] rv64ilp32_abi: bpf: Change KERN_ARENA_SZ to 256MiB guoren
2025-03-25 12:16 ` [RFC PATCH V3 23/43] rv64ilp32_abi: compat: Correct compat_ulong_t cast guoren
2025-03-25 12:16 ` [RFC PATCH V3 24/43] rv64ilp32_abi: compiler_types: Add "long long" into __native_word() guoren
2025-03-25 12:16 ` [RFC PATCH V3 25/43] rv64ilp32_abi: exec: Adapt 64lp64 env and argv guoren
2025-03-25 17:19 ` Sergey Shtylyov
2025-03-26 9:22 ` Guo Ren
2025-03-25 12:16 ` [RFC PATCH V3 26/43] rv64ilp32_abi: file_ref: Use 32-bit width for refcnt guoren
2025-03-25 12:16 ` [RFC PATCH V3 27/43] rv64ilp32_abi: input: Adapt BITS_PER_LONG to dword guoren
2025-03-25 12:16 ` [RFC PATCH V3 28/43] rv64ilp32_abi: iov_iter: Resize kvec to match iov_iter's size guoren
2025-03-25 12:16 ` [RFC PATCH V3 29/43] rv64ilp32_abi: locking/atomic: Use BITS_PER_LONG for scripts guoren
2025-03-25 12:16 ` [RFC PATCH V3 30/43] rv64ilp32_abi: kernel/smp: Disable CSD_LOCK_WAIT_DEBUG guoren
2025-03-25 12:16 ` [RFC PATCH V3 31/43] rv64ilp32_abi: maple_tree: Use BITS_PER_LONG instead of CONFIG_64BIT guoren
2025-03-25 19:09 ` Liam R. Howlett
2025-03-27 12:47 ` Guo Ren
2025-03-25 12:16 ` [RFC PATCH V3 32/43] rv64ilp32_abi: mm: Remove _folio_nr_pages guoren
2025-03-25 12:16 ` [RFC PATCH V3 33/43] rv64ilp32_abi: mm/auxvec: Adapt mm->saved_auxv[] to Elf64 guoren
2025-03-25 12:16 ` [RFC PATCH V3 34/43] rv64ilp32_abi: mm: Adapt vm_flags_t struct guoren
2025-03-25 12:16 ` [RFC PATCH V3 35/43] rv64ilp32_abi: net: Use BITS_PER_LONG in struct dst_entry guoren
2025-03-25 12:16 ` [RFC PATCH V3 36/43] rv64ilp32_abi: printf: Use BITS_PER_LONG instead of CONFIG_64BIT guoren
2025-03-25 12:16 ` [RFC PATCH V3 37/43] rv64ilp32_abi: random: Adapt fast_pool struct guoren
2025-03-25 12:16 ` [RFC PATCH V3 38/43] rv64ilp32_abi: syscall: Use CONFIG_64BIT instead of BITS_PER_LONG guoren
2025-03-25 12:16 ` [RFC PATCH V3 39/43] rv64ilp32_abi: sysinfo: Adapt sysinfo structure to lp64 uapi guoren
2025-03-25 12:16 ` [RFC PATCH V3 40/43] rv64ilp32_abi: tracepoint-defs: Using u64 for trace_print_flags.mask guoren
2025-03-25 12:16 ` [RFC PATCH V3 41/43] rv64ilp32_abi: tty: Adapt ptr_to_compat guoren
2025-03-25 12:16 ` [RFC PATCH V3 42/43] rv64ilp32_abi: memfd: Use vm_flag_t guoren
2025-03-25 12:16 ` [RFC PATCH V3 43/43] riscv: Fixup address space overlay of print_mlk guoren
2025-03-25 12:26 ` [RFC PATCH V3 00/43] rv64ilp32_abi: Build CONFIG_64BIT kernel-self with ILP32 ABI Peter Zijlstra
2025-03-25 13:13 ` Guo Ren
2025-03-25 13:17 ` Arnd Bergmann
2025-03-26 6:07 ` Guo Ren
2025-03-26 6:55 ` Arnd Bergmann
2025-03-27 13:13 ` Guo Ren
2025-03-25 18:51 ` David Hildenbrand
2025-03-25 19:23 ` Liam R. Howlett
2025-03-27 16:20 ` Palmer Dabbelt
2025-03-27 21:06 ` David Laight
2025-03-31 9:38 ` Guo Ren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250325121624.523258-6-guoren@kernel.org \
--to=guoren@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=anup@brainfault.org \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=ast@kernel.org \
--cc=atishp@atishpatra.org \
--cc=boqun.feng@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=conor.dooley@microchip.com \
--cc=coreteam@netfilter.org \
--cc=ctsai390@andestech.com \
--cc=cuiyunhui@bytedance.com \
--cc=david@redhat.com \
--cc=drew@pdp7.com \
--cc=dsterba@suse.com \
--cc=edumazet@google.com \
--cc=gaohan@iscas.ac.cn \
--cc=gregkh@linuxfoundation.org \
--cc=inochiama@outlook.com \
--cc=jiawei@iscas.ac.cn \
--cc=josef@toxicpanda.com \
--cc=jszhang@kernel.org \
--cc=kees@kernel.org \
--cc=kuba@kernel.org \
--cc=kvm-riscv@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=leobras@redhat.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-atm-general@lists.sourceforge.net \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-sctp@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=luxu.kernel@bytedance.com \
--cc=maple-tree@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=pabeni@redhat.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=peterz@infradead.org \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
--cc=qiaozhe@iscas.ac.cn \
--cc=qingfang.deng@siflower.com.cn \
--cc=rostedt@goodmis.org \
--cc=ruanjinjie@huawei.com \
--cc=samuel.holland@sifive.com \
--cc=shihua@iscas.ac.cn \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=unicorn_wang@outlook.com \
--cc=wangkefeng.wang@huawei.com \
--cc=wefu@redhat.com \
--cc=will@kernel.org \
--cc=wuwei2016@iscas.ac.cn \
--cc=xiao.w.wang@intel.com \
--cc=yongxuan.wang@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox