Re: [PATCH v6 1/1] eal/riscv: optimize rte_memcpy with vector and zicbop extensions

chen.qiguo at zte.com.cn chen.qiguo at zte.com.cn
Mon Nov 17 10:12:42 CET 2025


> > # 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 at iscas.ac.cn>
To: 陈其国10108961;stanislaw.kardach at gmail.com <stanislaw.kardach at gmail.com>;stephen at networkplumber.org <stephen at networkplumber.org>;
Cc: dev at dpdk.org <dev at dpdk.org>;bruce.richardson at intel.com <bruce.richardson at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/dev/attachments/20251117/c6437ac5/attachment-0001.htm>


More information about the dev mailing list