[dpdk-dev] Compiler hardening flags for libraries and performance implications
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Matthew Hall > Sent: Tuesday, July 26, 2016 5:44 PM > To: Luca Boccassi > Cc: dev at dpdk.org; christian.ehrhardt at canonical.com; > cjcollier at linuxfoundation.org; ricardo.salveti at linaro.org > Subject: Re: [dpdk-dev] Compiler hardening flags for libraries and > performance implications > > On Tue, Jul 26, 2016 at 02:53:13PM +, 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. Hi Matthew, Maybe you kick this off and submit something to the new howto section of the docs with whatever tuning tips you have so far. Then we can get people to contribute over time until we have something more useful. John
[dpdk-dev] Compiler hardening flags for libraries and performance implications
On Wed, Jul 27, 2016 at 12:58:12PM +, Mcnamara, John wrote: > Hi Matthew, > > Maybe you kick this off and submit something to the new howto section of the > docs with whatever tuning tips you have so far. > > Then we can get people to contribute over time until we have something more > useful. > > John Believe me, I'd really love to do so but I really don't have any clue about CFLAGS, how to find the problematic LOCs for CPU usage, cache misses, etc. I think I wrote some previous mails about different challenges I ran into. I feel like there is a certain amount of knowledge inside of Intel and 6WIND about these things that hasn't propagated to the rest of the community. Maybe we could find a way to have some hackathons in Silicon Valley where people could work on code or projects together? Then we could see about spreading and documenting some of the organic knowledge to improve the coding and tuning guides. The Meetups seem to demo new features but they don't talk about testing and tuning there sadly. I'm really up for any ideas, it's something I struggled with ever since the beginning of when I used DPDK 1.x in 2011. Matthew.
[dpdk-dev] Compiler hardening flags for libraries and performance implications
Hello, 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. Especially 2 of the hardening options provided on Debian/Ubuntu [1] explicitly cite performance implications: - "bind now" (ld -z now), which forces to resolve all dynamic symbols immediately at load - "stack protector" (-fstack-protector-strong), which adds safety checks against stack overwrites Any opinions? Would anyone have reservations if we enabled all of these in the packages that will be distributed in Ubuntu and Debian? Thanks! -- Kind regards, Luca Boccassi [1] https://wiki.debian.org/Hardening#Environment_variables
[dpdk-dev] Compiler hardening flags for libraries and performance implications
On Tue, Jul 26, 2016 at 02:53:13PM +, 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.
