From: "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>,
Ruifeng Wang <ruifeng.wang@arm.com>
Cc: bruce.richardson@intel.com, dev@dpdk.org,
honnappa.nagarahalli@arm.com, gavin.hu@arm.com, nd@arm.com
Subject: Re: [dpdk-dev] [PATCH v3 1/3] lib/lpm: not inline unnecessary functions
Date: Fri, 28 Jun 2019 14:38:21 +0100 [thread overview]
Message-ID: <94ab5030-f138-1ea4-8dbd-d67dc24a72a8@intel.com> (raw)
In-Reply-To: <20190627082451.56719392@hermes.lan>
Hi Stephen,
On 27/06/2019 16:24, Stephen Hemminger wrote:
> On Thu, 27 Jun 2019 17:37:49 +0800
> Ruifeng Wang <ruifeng.wang@arm.com> wrote:
>
>> Tests showed that the function inlining caused performance drop
>> on some x86 platforms with the memory ordering patches applied.
>> By force no-inline functions, the performance was better than
>> before on x86 and no impact to arm64 platforms.
>>
>> Suggested-by: Medvedkin Vladimir <vladimir.medvedkin@intel.com>
>> Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
>> Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> {
>
> Do you actually need to force noinline or is just taking of inline enough?
> In general, letting compiler decide is often best practice.
In some cases compiler inlines this functions even if they don't have an
inline qualifier. On some processors it leads to performance drop (maybe
because of icache trashing).
--
Regards,
Vladimir
prev parent reply other threads:[~2019-06-28 13:38 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-27 9:37 Ruifeng Wang
2019-06-27 9:37 ` [dpdk-dev] [PATCH v3 2/3] lib/lpm: memory orderings to avoid race conditions for v1604 Ruifeng Wang
2019-06-27 9:37 ` [dpdk-dev] [PATCH v3 3/3] lib/lpm: memory orderings to avoid race conditions for v20 Ruifeng Wang
2019-06-28 13:33 ` Medvedkin, Vladimir
2019-06-29 17:35 ` Honnappa Nagarahalli
2019-07-05 13:45 ` Alex Kiselev
2019-07-05 16:56 ` Medvedkin, Vladimir
2019-07-01 7:08 ` Ruifeng Wang (Arm Technology China)
2019-06-27 15:24 ` [dpdk-dev] [PATCH v3 1/3] lib/lpm: not inline unnecessary functions Stephen Hemminger
2019-06-28 2:44 ` Ruifeng Wang (Arm Technology China)
2019-06-28 4:34 ` Stephen Hemminger
2019-06-28 5:48 ` Ruifeng Wang (Arm Technology China)
2019-06-28 13:47 ` Medvedkin, Vladimir
2019-06-28 13:57 ` Honnappa Nagarahalli
2019-06-28 14:16 ` Medvedkin, Vladimir
2019-06-28 15:35 ` Stephen Hemminger
2019-07-01 6:44 ` Ruifeng Wang (Arm Technology China)
2019-07-05 10:40 ` Medvedkin, Vladimir
2019-07-05 10:58 ` Ruifeng Wang (Arm Technology China)
2019-07-05 10:31 ` Medvedkin, Vladimir
2019-07-05 13:37 ` Alex Kiselev
2019-07-05 16:53 ` Medvedkin, Vladimir
2019-06-28 13:38 ` Medvedkin, Vladimir [this message]
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=94ab5030-f138-1ea4-8dbd-d67dc24a72a8@intel.com \
--to=vladimir.medvedkin@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=gavin.hu@arm.com \
--cc=honnappa.nagarahalli@arm.com \
--cc=nd@arm.com \
--cc=ruifeng.wang@arm.com \
--cc=stephen@networkplumber.org \
/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).