From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 91A395686 for ; Fri, 15 Jan 2016 07:39:06 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 14 Jan 2016 22:39:05 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,298,1449561600"; d="scan'208";a="893655674" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga002.fm.intel.com with ESMTP; 14 Jan 2016 22:39:05 -0800 Received: from fmsmsx157.amr.corp.intel.com (10.18.116.73) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 14 Jan 2016 22:39:04 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX157.amr.corp.intel.com (10.18.116.73) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 14 Jan 2016 22:39:03 -0800 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.218]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.231]) with mapi id 14.03.0248.002; Fri, 15 Jan 2016 14:39:02 +0800 From: "Wang, Zhihong" To: Stephen Hemminger Thread-Topic: [PATCH 0/4] Optimize memcpy for AVX512 platforms Thread-Index: AQHRTs3VkXqWe+rMXEqfAWLYjJINJ576sxUAgAFm6bA= Date: Fri, 15 Jan 2016 06:39:01 +0000 Message-ID: <8F6C2BD409508844A0EFC19955BE0941033A63DA@SHSMSX103.ccr.corp.intel.com> References: <1452752002-107586-1-git-send-email-zhihong.wang@intel.com> <20160114084832.672fac86@xeon-e3> In-Reply-To: <20160114084832.672fac86@xeon-e3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDE2YmNlODgtNjIxZC00NzY0LWI0MjUtZGFkZTFhOTljMjM3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjQuMTAuMTkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiblVVd1paajhPb0FcL1grM1kxM1lnUjYycHp1MWNKVXF4OXVLREgwdjVtd009In0= x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH 0/4] Optimize memcpy for AVX512 platforms X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 06:39:07 -0000 > -----Original Message----- > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Friday, January 15, 2016 12:49 AM > To: Wang, Zhihong > Cc: dev@dpdk.org; Ananyev, Konstantin ; > Richardson, Bruce ; Xie, Huawei > > Subject: Re: [PATCH 0/4] Optimize memcpy for AVX512 platforms >=20 > On Thu, 14 Jan 2016 01:13:18 -0500 > Zhihong Wang wrote: >=20 > > This patch set optimizes DPDK memcpy for AVX512 platforms, to make full > > utilization of hardware resources and deliver high performance. > > > > In current DPDK, memcpy holds a large proportion of execution time in > > libs like Vhost, especially for large packets, and this patch can bring > > considerable benefits. > > > > The implementation is based on the current DPDK memcpy framework, some > > background introduction can be found in these threads: > > http://dpdk.org/ml/archives/dev/2014-November/008158.html > > http://dpdk.org/ml/archives/dev/2015-January/011800.html > > > > Code changes are: > > > > 1. Read CPUID to check if AVX512 is supported by CPU > > > > 2. Predefine AVX512 macro if AVX512 is enabled by compiler > > > > 3. Implement AVX512 memcpy and choose the right implementation based > on > > predefined macros > > > > 4. Decide alignment unit for memcpy perf test based on predefined mac= ros > > > > Zhihong Wang (4): > > lib/librte_eal: Identify AVX512 CPU flag > > mk: Predefine AVX512 macro for compiler > > lib/librte_eal: Optimize memcpy for AVX512 platforms > > app/test: Adjust alignment unit for memcpy perf test > > > > app/test/test_memcpy_perf.c | 6 + > > .../common/include/arch/x86/rte_cpuflags.h | 2 + > > .../common/include/arch/x86/rte_memcpy.h | 247 > ++++++++++++++++++++- > > mk/rte.cpuflags.mk | 4 + > > 4 files changed, 255 insertions(+), 4 deletions(-) > > >=20 > This really looks like code that could benefit from Gcc > function multiversioning. The current cpuflags model is useless/flawed > in real product deployment I've tried gcc function multi versioning, with a simple add() function which returns a + b, and a loop calling it for millions of times. Turned out this mechanism adds 17% extra time to execute, overall it's a lot of extra overhead. Quote the gcc wiki: "GCC takes care of doing the dispatching to call the right version at runtime". So it loses inlining and adds extra dispatching overhead. Also this mechanism works only for C++, right? I think using predefined macros at compile time is more efficient and suits DPDK more. Could you please give an example when the current CPU flags model stop working? So I can fix it.