From mboxrd@z Thu Jan 1 00:00:00 1970 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) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=p1bOcLV5PkKNEBZMUfGdq8K+dHA+5KoDBdi7uYK1Evs=; b=bgmcZRttdfG9AtV3HQG1T/kgC2LKO0hsEZt2wOEKKKNzUNHY3FRPJIGvHe2iBvTd5b omMibkICynUeFkQKot6p/ayQWVCuHk3VK12qS7r7JVKTM144xkIbbuIowj0kc34R/iDP P+RiGoPDAlYQer41jHKVY2b8mdffUSn6hH8QYPNolLFP4q7m0cOquA8NR6m5i+15aSuO PouaRJy5+ydclXfJMy2g6X/faMPNKBJf4FDDY/d2Y+rygX9PRFJNaeW+cys9Mkt0CybS qrMnPp4FLvPI5S3k9Nh2Q35lTEmM82UHvu+ymiNsm9f1wFzmx5zqPo36j2BjQ2ljHJTD qD5g== X-Gm-Message-State: ALoCoQnbosyy02lnfvYScA4BKpBUamGxwStnbTeaulJmmervlVudWwp3zyhxnIQ2iY2169L0mGyl X-Received: by 10.66.141.12 with SMTP id rk12mr11422304pab.34.1445442457879; Wed, 21 Oct 2015 08:47:37 -0700 (PDT) Received: from xeon-e3 (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by smtp.gmail.com with ESMTPSA id nu5sm9824386pbb.65.2015.10.21.08.47.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Oct 2015 08:47:37 -0700 (PDT) Date: Wed, 21 Oct 2015 08:47:47 -0700 From: Stephen Hemminger To: "Ananyev, Konstantin" Message-ID: <20151021084747.6c2ca303@xeon-e3> In-Reply-To: <2601191342CEEE43887BDE71AB97725836AB321F@irsmsx105.ger.corp.intel.com> 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 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:47:39 -0000 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.