DPDK usage discussions
 help / color / mirror / Atom feed
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









             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).