From: "Yang, Zhiyong" <zhiyong.yang@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"yuanhan.liu@linux.intel.com" <yuanhan.liu@linux.intel.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
"De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
Subject: Re: [dpdk-dev] [PATCH 1/4] eal/common: introduce rte_memset on IA platform
Date: Thu, 8 Dec 2016 07:41:43 +0000 [thread overview]
Message-ID: <E182254E98A5DA4EB1E657AC7CB9BD2A3EB565EC@BGSMSX101.gar.corp.intel.com> (raw)
In-Reply-To: <7223515.9TZuZb6buy@xps13>
HI, Thomas:
Sorry for late reply. I have been being always considering your suggestion.
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Friday, December 2, 2016 6:25 PM
> To: Yang, Zhiyong <zhiyong.yang@intel.com>
> Cc: dev@dpdk.org; yuanhan.liu@linux.intel.com; Richardson, Bruce
> <bruce.richardson@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>
> Subject: Re: [dpdk-dev] [PATCH 1/4] eal/common: introduce rte_memset on
> IA platform
>
> 2016-12-05 16:26, Zhiyong Yang:
> > +#ifndef _RTE_MEMSET_X86_64_H_
>
> Is this implementation specific to 64-bit?
>
Yes.
> > +
> > +#define rte_memset memset
> > +
> > +#else
> > +
> > +static void *
> > +rte_memset(void *dst, int a, size_t n);
> > +
> > +#endif
>
> If I understand well, rte_memset (as rte_memcpy) is using the most recent
> instructions available (and enabled) when compiling.
> It is not adapting the instructions to the run-time CPU.
> There is no need to downgrade at run-time the instruction set as it is
> obviously not a supported case, but it would be nice to be able to upgrade a
> "default compilation" at run-time as it is done in rte_acl.
> I explain this case more clearly for reference:
>
> We can have AVX512 supported in the compiler but disable it when compiling
> (CONFIG_RTE_MACHINE=snb) in order to build a binary running almost
> everywhere.
> When running this binary on a CPU having AVX512 support, it will not benefit
> of the AVX512 improvement.
> Though, we can compile an AVX512 version of some functions and use them
> only if the running CPU is capable.
> This kind of miracle can be achieved in two ways:
>
> 1/ For generic C code compiled with a recent GCC, a function can be built for
> several CPUs thanks to the attribute target_clones.
>
> 2/ For manually optimized functions using CPU-specific intrinsics or asm, it is
> possible to build them with non-default flags thanks to the attribute target.
>
> 3/ For manually optimized files using CPU-specific intrinsics or asm, we use
> specifics flags in the makefile.
>
> The function clone in case 1/ is dynamically chosen at run-time through ifunc
> resolver.
> The specific functions in cases 2/ and 3/ must chosen at run-time by
> initializing a function pointer thanks to rte_cpu_get_flag_enabled().
>
> Note that rte_hash and software crypto PMDs have a run-time check with
> rte_cpu_get_flag_enabled() but do not override CFLAGS in the Makefile.
> Next step for these libraries?
>
> Back to rte_memset, I think you should try the solution 2/.
I have read the ACL code, if I understand well , for complex algo implementation,
it is good idea, but Choosing functions at run time will bring some overhead. For frequently called function
Which consumes small cycles, the overhead maybe is more than the gains optimizations brings
For example, for most applications in dpdk, memset only set N = 10 or 12bytes. It consumes fewer cycles.
Thanks
Zhiyong
next prev parent reply other threads:[~2016-12-08 7:41 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-05 8:26 [dpdk-dev] [PATCH 0/4] eal/common: introduce rte_memset and related test Zhiyong Yang
2016-12-02 10:00 ` Maxime Coquelin
2016-12-06 6:33 ` Yang, Zhiyong
2016-12-06 8:29 ` Maxime Coquelin
2016-12-07 9:28 ` Yang, Zhiyong
2016-12-07 9:37 ` Yuanhan Liu
2016-12-07 9:43 ` Yang, Zhiyong
2016-12-07 9:48 ` Yuanhan Liu
2016-12-05 8:26 ` [dpdk-dev] [PATCH 1/4] eal/common: introduce rte_memset on IA platform Zhiyong Yang
2016-12-02 10:25 ` Thomas Monjalon
2016-12-08 7:41 ` Yang, Zhiyong [this message]
2016-12-08 9:26 ` Ananyev, Konstantin
2016-12-08 9:53 ` Yang, Zhiyong
2016-12-08 10:27 ` Bruce Richardson
2016-12-08 10:30 ` Ananyev, Konstantin
2016-12-11 12:32 ` Yang, Zhiyong
2016-12-15 6:51 ` Yang, Zhiyong
2016-12-15 10:12 ` Bruce Richardson
2016-12-16 10:19 ` Yang, Zhiyong
2016-12-19 6:27 ` Yuanhan Liu
2016-12-20 2:41 ` Yao, Lei A
2016-12-15 10:53 ` Ananyev, Konstantin
2016-12-16 2:15 ` Yang, Zhiyong
2016-12-16 11:47 ` Ananyev, Konstantin
2016-12-20 9:31 ` Yang, Zhiyong
2016-12-08 15:09 ` Thomas Monjalon
2016-12-11 12:04 ` Yang, Zhiyong
2016-12-27 10:04 ` [dpdk-dev] [PATCH v2 0/4] eal/common: introduce rte_memset and related test Zhiyong Yang
2016-12-27 10:04 ` [dpdk-dev] [PATCH v2 1/4] eal/common: introduce rte_memset on IA platform Zhiyong Yang
2016-12-27 10:04 ` [dpdk-dev] [PATCH v2 2/4] app/test: add functional autotest for rte_memset Zhiyong Yang
2016-12-27 10:04 ` [dpdk-dev] [PATCH v2 3/4] app/test: add performance " Zhiyong Yang
2016-12-27 10:04 ` [dpdk-dev] [PATCH v2 4/4] lib/librte_vhost: improve vhost perf using rte_memset Zhiyong Yang
2017-01-09 9:48 ` [dpdk-dev] [PATCH v2 0/4] eal/common: introduce rte_memset and related test Yang, Zhiyong
2017-01-17 6:24 ` Yang, Zhiyong
2017-01-17 20:14 ` Thomas Monjalon
2017-01-18 0:15 ` Vincent JARDIN
2017-01-18 2:42 ` Yang, Zhiyong
2017-01-18 7:42 ` Thomas Monjalon
2017-01-19 1:36 ` Yang, Zhiyong
2016-12-05 8:26 ` [dpdk-dev] [PATCH 2/4] app/test: add functional autotest for rte_memset Zhiyong Yang
2016-12-05 8:26 ` [dpdk-dev] [PATCH 3/4] app/test: add performance " Zhiyong Yang
2016-12-05 8:26 ` [dpdk-dev] [PATCH 4/4] lib/librte_vhost: improve vhost perf using rte_memset Zhiyong Yang
2016-12-02 9:46 ` Thomas Monjalon
2016-12-06 8:04 ` Yang, Zhiyong
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=E182254E98A5DA4EB1E657AC7CB9BD2A3EB565EC@BGSMSX101.gar.corp.intel.com \
--to=zhiyong.yang@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@intel.com \
--cc=pablo.de.lara.guarch@intel.com \
--cc=thomas.monjalon@6wind.com \
--cc=yuanhan.liu@linux.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).