From: Yuyong Zhang <yuyong.zhang@casa-systems.com>
To: "users@dpdk.org" <users@dpdk.org>
Subject: [dpdk-users] compile warning in dpdk lib header files "error: inlining failed in call .... call is unlikely and code size would grow"
Date: Fri, 8 Sep 2017 18:45:52 +0000 [thread overview]
Message-ID: <BN6PR06MB2756A0BB9A23CB1FB6350242B9950@BN6PR06MB2756.namprd06.prod.outlook.com> (raw)
Hi,
I got lots of compile warning when integrating dpdk library such as:
: error: inlining failed in call to ‘rte_mempool_ops_dequeue_bulk.part.1’: call is unlikely and code size would grow [-Werror=inline]
: error: inlining failed in call to ‘rte_pktmbuf_free": call is unlikely and code size would grow [-Werror=inline]
Because company policy strictly enforces "waring as error", I have to fix those issues.
I can have an option to use –Wno-error=inline in make file to suppress these warnings. However we are building data plane application, performance is one of the biggest requirements, thus another option is to modify header files such as in rte_mbuf.h to add __attribute__((always_inlie)) i.e adding:
static inline void rte_pktmbuf_free(struct rte_mbuf *m) __attribute__((always_inline));
static inline void rte_pktmbuf_free(struct rte_mbuf *m)
1. The assumptions is that Intel and others do a lot of performance testing on the DPDK, and there are specific functions that are always inlined already, is it on purpose for inline functions such as rte_pktmbuf_free not using always_inline?
2. Which one is better for performance: using –Wno-error=inline vs adding __attribute__((always_inline)) to warned inline function header files?
Any inputs are appreciated.
Regards,
Yuyong
next reply other threads:[~2017-09-08 18:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-08 18:45 Yuyong Zhang [this message]
2017-09-08 19:08 ` Stephen Hemminger
2017-09-08 19:15 ` Yuyong Zhang
2017-09-08 21:51 ` Stephen Hemminger
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=BN6PR06MB2756A0BB9A23CB1FB6350242B9950@BN6PR06MB2756.namprd06.prod.outlook.com \
--to=yuyong.zhang@casa-systems.com \
--cc=users@dpdk.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).