DPDK patches and discussions
 help / color / mirror / Atom feed
From: Matthew Hall <mhall@mhcomputing.net>
To: Luca Boccassi <lboccass@Brocade.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"christian.ehrhardt@canonical.com"
	<christian.ehrhardt@canonical.com>,
	"cjcollier@linuxfoundation.org" <cjcollier@linuxfoundation.org>,
	"ricardo.salveti@linaro.org" <ricardo.salveti@linaro.org>
Subject: Re: [dpdk-dev] Compiler hardening flags for libraries and performance implications
Date: Tue, 26 Jul 2016 09:44:22 -0700	[thread overview]
Message-ID: <20160726164422.GB1484@mhcomputing.net> (raw)
In-Reply-To: <1469544793.4240.24.camel@brocade.com>

On Tue, Jul 26, 2016 at 02:53:13PM +0000, Luca Boccassi wrote:
> While working on uploading DPDK to Ubuntu and Debian, we were wondering
> if anyone had any thoughts/opinions on enabling compiler hardening flags
> for the DPDK libraries and the possible performance implications.

Most of the C profilers, both VTune and Perf based tools, have not given me 
that much helpful data. They make it very hard to go from slow functions down 
to actual slow lines of code causing performance issues that I should fix. So 
I would love to see a MUCH better DPDK tuning guide, because the current one 
is really generic and gives no useful advice beyond what any programmer has 
already heard many times that doesn't really add much value.

This issue aside, in general I found that all the bounds-checking stuff, 
various FORTIFY_SOURCE items, and other supposedly "helpful" code security 
functions were chewing up a lot of CPU resources in the profiling output, and 
obscuring the actual slow parts of code being executed in the profiling runs. 
This stuff was making it difficult for me to optimize my code effectively, 
because they replace readable things which exist in real files and have 
symbols with wrappers that don't have working symbols and such.

> Any opinions? Would anyone have reservations if we enabled all of these
> in the packages that will be distributed in Ubuntu and Debian?

Based on the bad stuff that happened to me, I had to disable all these things 
to get useful results and start making the code run faster. But it would be 
nice to have some better advice on profilers and do some actual measurements 
before-and-after to see if my experiences are repeatable.

Matthew.

  reply	other threads:[~2016-07-26 16:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-26 14:53 Luca Boccassi
2016-07-26 16:44 ` Matthew Hall [this message]
2016-07-27 12:58   ` Mcnamara, John
2016-07-27 15:46     ` Matthew Hall

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=20160726164422.GB1484@mhcomputing.net \
    --to=mhall@mhcomputing.net \
    --cc=christian.ehrhardt@canonical.com \
    --cc=cjcollier@linuxfoundation.org \
    --cc=dev@dpdk.org \
    --cc=lboccass@Brocade.com \
    --cc=ricardo.salveti@linaro.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).