From: <chen.qiguo@zte.com.cn>
To: <sunyuechi@iscas.ac.cn>
Cc: <stanislaw.kardach@gmail.com>, <stephen@networkplumber.org>,
<dev@dpdk.org>, <bruce.richardson@intel.com>
Subject: Re: [PATCH v6 1/1] eal/riscv: optimize rte_memcpy with vector and zicbop extensions
Date: Mon, 17 Nov 2025 17:12:42 +0800 (CST) [thread overview]
Message-ID: <20251117171242744Fq0vSapdYYdz90jM5IQWM@zte.com.cn> (raw)
In-Reply-To: <4615b675-6847-4f3b-925f-75df52be5bcc@iscas.ac.cn>
[-- Attachment #1.1.1: Type: text/plain, Size: 3900 bytes --]
> > # detect extensions > > # Requires intrinsics available in GCC 14.1.0+ and Clang 18.1.0+ > > if (riscv_extension_macros and > > (cc.get_define('__riscv_zicbop', args: machine_args) != '')) > > if ((cc.get_id() == 'gcc' and cc.version().version_compare('>=14.1.0')) > > or (cc.get_id() == 'clang' and cc.version().version_compare('>=18.1.0'))) > > message('Compiling with the zicbop extension') > > machine_args += ['-DRTE_RISCV_FEATURE_PREFETCH'] > > else > > warning('Detected zicbop extension but cannot use because intrinsics are not available (present in GCC 14.1.0+ and Clang 18.1.0+)') > > endif > > endif > > The implementation does not involve intrinsicsIt looks like nothing has been changed here yet.--------------sorry, i did not notice this. i'll revise it later.
With the current compilation conditions, if zicbop isn’t supported, the v-optimization also won’t be compiled.Have you tested the performance difference if you remove these prefetches and only use v? ----------------yes. when we use vector but without zicbop, the performance is worse than memcpy.Can we use a condition like this to support only v?---------Since the code affects several areas and for the reason mentioned above, I prefer to keep the current logic, as it looks simpler.
Thanks again for your review.
Original
From: sunyuechi <sunyuechi@iscas.ac.cn>
To: 陈其国10108961;stanislaw.kardach@gmail.com <stanislaw.kardach@gmail.com>;stephen@networkplumber.org <stephen@networkplumber.org>;
Cc: dev@dpdk.org <dev@dpdk.org>;bruce.richardson@intel.com <bruce.richardson@intel.com>;
Date: 2025年11月17日 12:19
Subject: Re: [PATCH v6 1/1] eal/riscv: optimize rte_memcpy with vector and zicbop extensions
> > # detect extensions
> > # Requires intrinsics available in GCC 14.1.0+ and Clang 18.1.0+
> > if (riscv_extension_macros and
> > (cc.get_define('__riscv_zicbop', args: machine_args) != ''))
> > if ((cc.get_id() == 'gcc' and
cc.version().version_compare('>=14.1.0'))
> > or (cc.get_id() == 'clang' and
cc.version().version_compare('>=18.1.0')))
> > message('Compiling with the zicbop extension')
> > machine_args += ['-DRTE_RISCV_FEATURE_PREFETCH']
> > else
> > warning('Detected zicbop extension but cannot use because
intrinsics are not available (present in GCC 14.1.0+ and Clang 18.1.0+)')
> > endif
> > endif
>
> The implementation does not involve intrinsics
It looks like nothing has been changed here yet.
> #if defined(RTE_RISCV_FEATURE_V) &&
!(defined(RTE_RISCV_FEATURE_PREFETCH))
> #undef RTE_RISCV_FEATURE_V
> #endif
>
> static __rte_always_inline void
> _rte_mov128blocks(uint8_t *dst, const uint8_t *src, size_t n)
> {
> asm volatile (
> "prefetch.r 64(%1)\n"
> "prefetch.w 64(%0)\n"
> "prefetch.r 128(%1)\n"
> "prefetch.w 128(%0)\n"
> "prefetch.r 192(%1)\n"
> "prefetch.w 192(%0)\n"
> "prefetch.r 256(%1)\n"
> "prefetch.w 256(%0)\n"
> "prefetch.r 320(%1)\n"
> "prefetch.w 320(%0)\n"
> "prefetch.r 384(%1)\n"
> "prefetch.w 384(%0)\n"
> "prefetch.r 448(%1)\n"
> "prefetch.w 448(%0)\n"
> "prefetch.r 512(%1)\n"
> "li t6, 512\n"
> "3:\n"
> "li t5, 128;"
> "vsetvli zero, t5, e8, m8, ta, ma\n"
With the current compilation conditions, if zicbop isn’t supported, the
v-optimization also won’t be compiled.
Have you tested the performance difference if you remove these
prefetches and only use v?
Can we use a condition like this to support only v?
#if defined(RTE_RISCV_FEATURE_V)
#if (defined(RTE_RISCV_FEATURE_PREFETCH))
...
#endif
...
#endif
[-- Attachment #1.1.2: Type: text/html , Size: 9845 bytes --]
next prev parent reply other threads:[~2025-11-17 9:13 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-16 9:09 [PATCH v1 0/2] Optimization Summary for RISC-V rte_memcpy Qiguo Chen
2025-10-16 9:09 ` [PATCH v1 1/2] riscv support rte_memcpy in vector Qiguo Chen
2025-10-17 5:29 ` sunyuechi
2025-10-17 10:10 ` chen.qiguo
2025-10-17 9:36 ` [PATCH v2 0/1] Optimization Summary for RISC-V rte_memcpy Qiguo Chen
2025-10-17 9:36 ` [PATCH v2 1/1] riscv support rte_memcpy in vector Qiguo Chen
2025-10-20 9:43 ` sunyuechi
2025-10-20 12:08 ` [PATCH v3 0/1] Optimization Summary for RISC-V rte_memcpy Qiguo Chen
2025-10-20 12:08 ` [PATCH v3 1/1] lib/eal/riscv: optimize rte_memcpy with RISCV vector and zicbop extensions Qiguo Chen
2025-10-21 6:56 ` [PATCH v4 0/1] Optimization Summary for RISC-V rte_memcpy Qiguo Chen
2025-10-21 6:56 ` [PATCH v4 1/1] eal/riscv: optimize rte_memcpy with vector and zicbop extensions Qiguo Chen
2025-10-24 2:56 ` retest Qiguo Chen
2025-10-30 15:35 ` retest Stephen Hemminger
2025-10-24 3:04 ` retest Qiguo Chen
2025-10-24 3:12 ` retest Qiguo Chen
2025-10-24 5:04 ` retest Qiguo Chen
2025-10-24 5:41 ` [PATCH v5 0/1] Optimization Summary for RISC-V rte_memcpy Qiguo Chen
2025-10-24 5:41 ` [PATCH v5 1/1] eal/riscv: optimize rte_memcpy with vector and zicbop extensions Qiguo Chen
2025-10-24 7:27 ` [PATCH v6 0/1] Optimization Summary for RISC-V rte_memcpy Qiguo Chen
2025-10-24 7:27 ` [PATCH v6 1/1] eal/riscv: optimize rte_memcpy with vector and zicbop extensions Qiguo Chen
2025-11-17 4:19 ` sunyuechi
2025-11-17 9:12 ` chen.qiguo [this message]
2025-10-24 16:27 ` [PATCH v5 " Stephen Hemminger
2025-11-17 4:11 ` sunyuechi
2025-10-16 9:09 ` [PATCH v1 2/2] benchmark report for rte_memcpy Qiguo Chen
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=20251117171242744Fq0vSapdYYdz90jM5IQWM@zte.com.cn \
--to=chen.qiguo@zte.com.cn \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=stanislaw.kardach@gmail.com \
--cc=stephen@networkplumber.org \
--cc=sunyuechi@iscas.ac.cn \
/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;
as well as URLs for NNTP newsgroup(s).