From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH v7 4/8] vhost: rxtx: use queue id instead of constant ring index Date: Wed, 21 Oct 2015 08:47:47 -0700 Message-ID: <20151021084747.6c2ca303@xeon-e3> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "Michael S. Tsirkin" , "dev@dpdk.org" , "marcel@redhat.com" , Changchun Ouyang To: "Ananyev, Konstantin" Return-path: Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by dpdk.org (Postfix) with ESMTP id 838D5C3F6 for ; Wed, 21 Oct 2015 17:47:38 +0200 (CEST) Received: by pabrc13 with SMTP id rc13so58167961pab.0 for ; Wed, 21 Oct 2015 08:47:37 -0700 (PDT) In-Reply-To: <2601191342CEEE43887BDE71AB97725836AB321F@irsmsx105.ger.corp.intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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.