From: Vincent JARDIN <vincent.jardin@6wind.com>
To: "Wang, Zhihong" <zhihong.wang@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/4] Optimize memcpy for AVX512 platforms
Date: Fri, 15 Jan 2016 23:03:28 +0100 [thread overview]
Message-ID: <CAG8AbRWDxvccOH0qYkMsd_WCEihNcn6z_9j8Y2p3Dg96=NSbfw@mail.gmail.com> (raw)
In-Reply-To: <8F6C2BD409508844A0EFC19955BE0941033A63DA@SHSMSX103.ccr.corp.intel.com>
Le 14 janv. 2016 22:39, "Wang, Zhihong" <zhihong.wang@intel.com> a écrit :
>
>
>
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Friday, January 15, 2016 12:49 AM
> > To: Wang, Zhihong <zhihong.wang@intel.com>
> > Cc: dev@dpdk.org; Ananyev, Konstantin <konstantin.ananyev@intel.com>;
> > Richardson, Bruce <bruce.richardson@intel.com>; Xie, Huawei
> > <huawei.xie@intel.com>
> > Subject: Re: [PATCH 0/4] Optimize memcpy for AVX512 platforms
> >
> > On Thu, 14 Jan 2016 01:13:18 -0500
> > Zhihong Wang <zhihong.wang@intel.com> wrote:
> >
> > > 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
macros
> > >
> > > 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(-)
> > >
> >
> > 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.
>
I agree with you: performance first.
So having a mix of runtime and compile time would work. For those who are
ok with some performance drops, they can go with runtime.
> Could you please give an example when the current CPU flags model
> stop working? So I can fix it.
>
next prev parent reply other threads:[~2016-01-15 22:03 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-14 6:13 Zhihong Wang
2016-01-14 6:13 ` [dpdk-dev] [PATCH 1/4] lib/librte_eal: Identify AVX512 CPU flag Zhihong Wang
2016-01-14 6:13 ` [dpdk-dev] [PATCH 2/4] mk: Predefine AVX512 macro for compiler Zhihong Wang
2016-01-14 6:13 ` [dpdk-dev] [PATCH 3/4] lib/librte_eal: Optimize memcpy for AVX512 platforms Zhihong Wang
2016-01-14 6:13 ` [dpdk-dev] [PATCH 4/4] app/test: Adjust alignment unit for memcpy perf test Zhihong Wang
2016-01-14 16:48 ` [dpdk-dev] [PATCH 0/4] Optimize memcpy for AVX512 platforms Stephen Hemminger
2016-01-15 6:39 ` Wang, Zhihong
2016-01-15 22:03 ` Vincent JARDIN [this message]
2016-01-18 3:05 ` [dpdk-dev] [PATCH v2 0/5] " Zhihong Wang
2016-01-18 3:05 ` [dpdk-dev] [PATCH v2 1/5] lib/librte_eal: Identify AVX512 CPU flag Zhihong Wang
2016-01-18 3:05 ` [dpdk-dev] [PATCH v2 2/5] mk: Predefine AVX512 macro for compiler Zhihong Wang
2016-01-18 3:05 ` [dpdk-dev] [PATCH v2 3/5] lib/librte_eal: Optimize memcpy for AVX512 platforms Zhihong Wang
2016-01-18 3:05 ` [dpdk-dev] [PATCH v2 4/5] app/test: Adjust alignment unit for memcpy perf test Zhihong Wang
2016-01-18 3:05 ` [dpdk-dev] [PATCH v2 5/5] lib/librte_eal: Tune memcpy for prior platforms Zhihong Wang
2016-01-18 20:06 ` [dpdk-dev] [PATCH v2 0/5] Optimize memcpy for AVX512 platforms Stephen Hemminger
2016-01-19 2:37 ` Wang, Zhihong
2016-01-27 15:23 ` Thomas Monjalon
2016-01-28 6:09 ` Wang, Zhihong
2016-01-27 15:30 ` Thomas Monjalon
2016-01-27 18:48 ` Ananyev, Konstantin
2016-01-27 20:18 ` Thomas Monjalon
2017-08-30 9:37 ` linhaifeng
2017-09-18 5:10 ` Wang, Zhihong
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='CAG8AbRWDxvccOH0qYkMsd_WCEihNcn6z_9j8Y2p3Dg96=NSbfw@mail.gmail.com' \
--to=vincent.jardin@6wind.com \
--cc=dev@dpdk.org \
--cc=zhihong.wang@intel.com \
/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).