From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 540DEC3C2 for ; Wed, 21 Oct 2015 17:55:44 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP; 21 Oct 2015 08:55:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,712,1437462000"; d="scan'208";a="585409604" Received: from bricha3-mobl3.ger.corp.intel.com (HELO [10.237.208.65]) ([10.237.208.65]) by FMSMGA003.fm.intel.com with ESMTP; 21 Oct 2015 08:55:41 -0700 To: Stephen Hemminger , "Ananyev, Konstantin" References: <1445399294-18826-1-git-send-email-yuanhan.liu@linux.intel.com> <1445399294-18826-5-git-send-email-yuanhan.liu@linux.intel.com> <20151020214354.12ac5ce1@xeon-e3> <2601191342CEEE43887BDE71AB97725836AB321F@irsmsx105.ger.corp.intel.com> <20151021084747.6c2ca303@xeon-e3> From: Bruce Richardson Message-ID: <5627B57D.7040603@intel.com> Date: Wed, 21 Oct 2015 16:55:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151021084747.6c2ca303@xeon-e3> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" , "marcel@redhat.com" , Changchun Ouyang , "Michael S. Tsirkin" Subject: Re: [dpdk-dev] [PATCH v7 4/8] vhost: rxtx: use queue id instead of constant ring index X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 15:55:44 -0000 On 21/10/2015 16:47, Stephen Hemminger wrote: > On Wed, 21 Oct 2015 09:38:37 +0000 > "Ananyev, Konstantin" wrote: > >>>> minor nits: >>>> * this doesn't need to be marked as always inline, >>>> that is as they say in English "shooting a fly with a bazooka" >>> Stephen: >>> always_inline "forces" the compiler to inline this function, like a macro. >>> When should it be used or is it not preferred at all? >> I also don't understand what's wrong with using 'always_inline' here. >> As I understand the author wants compiler to *always inline* that function. >> So seems perfectly ok to use it here. >> As I remember just 'inline' is sort of recommendation that compiler is free to ignore. >> Konstantin > I follow Linux/Linus advice and resist the urge to add strong inlining. > The compiler does a good job of deciding to inline, and many times > the reason it chooses for not inlining are quite good like: > - the code is on an unlikely branch > - register pressure means inlining would mean the code would be worse > > Therefore my rules are: > * only use inline for small functions. Let compiler decide on larger static funcs > * write code where most functions are static (localized scope) where compiler > can decide > * reserve always inline for things that access hardware and would break if not inlined. > On the other hand, there are cases where we know the compiler will likely inline, but we also know that not inlining could have a high performance penalty, and in that case marking as "always inline" would be appropriate - even though it is likely unnecessary for most compilers. In such a case, I would expect the verification check to be: explicitly mark the function as *not* to be inlined, and see what the perf drop is. If it's a noticable drop, marking as always-inline is an ok precaution against future compiler changes. Also, we need to remember that compilers cannot know whether a function is data path or not, and also whether a function will be called per-packet or per-burst. That's only something the programmer will know, and functions called per-packet on the datapath generally need to be inlined for performance. /Bruce /Bruce