[dpdk-dev] [PATCH 1/3] eal/x86: run-time dispatch over memcpy

[Lu, Wenzhuo]

Hi Bruce,

> -----Original Message-----
> From: Richardson, Bruce
> Sent: Thursday, August 31, 2017 1:52 AM
> To: Ananyev, Konstantin <konstantin.ananyev at intel.com>
> Cc: Li, Xiaoyun <xiaoyun.li at intel.com>; dev at dpdk.org; Lu, Wenzhuo
> <wenzhuo.lu at intel.com>; Wang, Zhihong <zhihong.wang at intel.com>; Zhang,
> Qi Z <qi.z.zhang at intel.com>
> Subject: Re: [dpdk-dev] [PATCH 1/3] eal/x86: run-time dispatch over memcpy
> 
> On Wed, Aug 30, 2017 at 03:56:35PM +0100, Ananyev, Konstantin wrote:
> >
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Xiaoyun Li
> > > Sent: Friday, August 25, 2017 3:06 AM
> > > To: Richardson, Bruce <bruce.richardson at intel.com>
> > > Cc: dev at dpdk.org; Lu, Wenzhuo <wenzhuo.lu at intel.com>; Wang,
> Zhihong
> > > <zhihong.wang at intel.com>; Zhang, Qi Z <qi.z.zhang at intel.com>; Li,
> > > Xiaoyun <xiaoyun.li at intel.com>
> > > Subject: [dpdk-dev] [PATCH 1/3] eal/x86: run-time dispatch over
> > > memcpy
> > >
> > > This patch dynamically selects functions of memcpy at run-time based
> > > on CPU flags that current machine supports. This patch uses function
> > > pointers which are bind to the relative functions at constrctor time.
> > > To make AVX512 instructions pass compilation, enable the switch in
> > > makefile.
> >
> > It seems quite an overhead to add extra function call for each 16B
> movement...
> > Wouldn't it be better to have one func_ptr per implementation, i.e:
> > rte_memcpy_sse(), rte_memcpy_avx2(), rte_memcpy_avx512(), etc.?
> > Konstantin
> >
> +1 to this.
> 
> Also, how big of a benefit is there for this implementation over standard libc
> memcpy (in a reasonably bleeding edge distro like e.g.
> Fedora 26)?
This patch is not an optimization. It only to make the code easier to use. So, the benefit is just the same as before.
I'm also curious about the benefit. Suppose it's better than standard libc. If not, maybe we should just use standard libc and this patch is not valuable.
+ Sergio, the maintainer of this module for more suggestion. Thanks.

> 
> /Bruce