From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id AE046FFA for ; Thu, 31 Aug 2017 03:21:56 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2017 18:21:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,451,1498546800"; d="scan'208";a="130146795" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga002.jf.intel.com with ESMTP; 30 Aug 2017 18:21:55 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 30 Aug 2017 18:21:54 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.39]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.93]) with mapi id 14.03.0319.002; Thu, 31 Aug 2017 09:21:16 +0800 From: "Lu, Wenzhuo" To: "Richardson, Bruce" , "Ananyev, Konstantin" , "Gonzalez Monroy, Sergio" CC: "Li, Xiaoyun" , "dev@dpdk.org" , "Wang, Zhihong" , "Zhang, Qi Z" Thread-Topic: [dpdk-dev] [PATCH 1/3] eal/x86: run-time dispatch over memcpy Thread-Index: AQHTHUbgSxBQ6olark6qfBV0AOXa7qKcf6+AgAAw7ICAAQI8kA== Date: Thu, 31 Aug 2017 01:21:15 +0000 Message-ID: <6A0DE07E22DDAD4C9103DF62FEBC09093B6A2D0E@shsmsx102.ccr.corp.intel.com> References: <1503626773-184682-1-git-send-email-xiaoyun.li@intel.com> <1503626773-184682-2-git-send-email-xiaoyun.li@intel.com> <2601191342CEEE43887BDE71AB9772584F23E343@IRSMSX103.ger.corp.intel.com> <20170830175140.GA11692@bricha3-MOBL3.ger.corp.intel.com> In-Reply-To: <20170830175140.GA11692@bricha3-MOBL3.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 1/3] eal/x86: run-time dispatch over memcpy X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 01:21:57 -0000 Hi Bruce, > -----Original Message----- > From: Richardson, Bruce > Sent: Thursday, August 31, 2017 1:52 AM > To: Ananyev, Konstantin > Cc: Li, Xiaoyun ; dev@dpdk.org; Lu, Wenzhuo > ; Wang, Zhihong ; Zhang, > Qi Z > Subject: Re: [dpdk-dev] [PATCH 1/3] eal/x86: run-time dispatch over memcp= y >=20 > On Wed, Aug 30, 2017 at 03:56:35PM +0100, Ananyev, Konstantin wrote: > > > > > > > -----Original Message----- > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Xiaoyun Li > > > Sent: Friday, August 25, 2017 3:06 AM > > > To: Richardson, Bruce > > > Cc: dev@dpdk.org; Lu, Wenzhuo ; Wang, > Zhihong > > > ; Zhang, Qi Z ; Li, > > > Xiaoyun > > > 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. >=20 > 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 valua= ble. + Sergio, the maintainer of this module for more suggestion. Thanks. >=20 > /Bruce