From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from compass.polito.it (compass.polito.it [130.192.55.110]) by dpdk.org (Postfix) with ESMTP id E0D8E569C for ; Fri, 18 Mar 2016 13:47:34 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by compass.polito.it (Postfix) with ESMTP id A2E041001A1 for ; Fri, 18 Mar 2016 13:47:33 +0100 (CET) Authentication-Results: compass.polito.it (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=studenti.polito.it DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= studenti.polito.it; h=content-type:content-type:cc:to:from:from :subject:subject:message-id:date:date:references:in-reply-to :received:mime-version:received:received:received; s=y2k10; t= 1458305252; bh=C8Rnysk5lhqq7pCYV5zinAKBe5iGVCrLlEczX3A3Ems=; b=i F/hykiFl8RlsxjNEEWysINTA5vWThJXXDCvhuobsOUTJyvn5UYreWr5l7EJ+E1ut vAwrQSn5hLl2CeuTt7XJizwESHe3Cnb8y513B9srK8WZJE5kOw53NxSd5vo4JDSA 8RarNuXCI+mdioKGToHfl1BQWjyvZfmLpswK8VpIoY= X-Virus-Scanned: amavisd-new at studenti.polito.it X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-100 required=3.5 tests=[ALL_TRUSTED=-5, AWL=0.647, BAYES_00=-1.5, HTML_MESSAGE=0.001] autolearn=unavailable Received: from compass.polito.it ([127.0.0.1]) by localhost (compass.polito.it [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id e7FM_f6XKcGe for ; Fri, 18 Mar 2016 13:47:32 +0100 (CET) Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com [209.85.215.47]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: s203403@studenti.polito.it) by compass.polito.it (Postfix) with ESMTPSA id 677071000C4 for ; Fri, 18 Mar 2016 13:47:30 +0100 (CET) Received: by mail-lf0-f47.google.com with SMTP id d82so18017031lfe.3 for ; Fri, 18 Mar 2016 05:47:30 -0700 (PDT) X-Gm-Message-State: AD7BkJL3nIcH3EvlcCsIFzAABS4XgFpnmczLb1bizH0idbssUucr/fwF/3kj7uBZTDLw9vuISxzaODLGNPtBzQ== MIME-Version: 1.0 X-Received: by 10.25.218.196 with SMTP id r187mr5930647lfg.6.1458305249707; Fri, 18 Mar 2016 05:47:29 -0700 (PDT) Received: by 10.25.23.166 with HTTP; Fri, 18 Mar 2016 05:47:29 -0700 (PDT) In-Reply-To: <17186869.jQBbCLbaVI@xps13> References: <1458229783-15547-1-git-send-email-l@nofutznetworks.com> <20160318101823.GC4848@bricha3-MOBL3> <56EBD806.8010707@6wind.com> <17186869.jQBbCLbaVI@xps13> Date: Fri, 18 Mar 2016 13:47:29 +0100 X-Gmail-Original-Message-ID: Message-ID: From: =?UTF-8?Q?Mauricio_V=C3=A1squez?= To: Thomas Monjalon Cc: dev@dpdk.org, Bruce Richardson , Olivier Matz , Lazaros Koromilas Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v2] ring: check for zero objects mc dequeue / mp enqueue 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: Fri, 18 Mar 2016 12:47:35 -0000 Hi, On Fri, Mar 18, 2016 at 11:35 AM, Thomas Monjalon wrote: > 2016-03-18 11:27, Olivier Matz: > > On 03/18/2016 11:18 AM, Bruce Richardson wrote: > > >>> + /* Avoid the unnecessary cmpset operation below, which is > also > > >>> + * potentially harmful when n equals 0. */ > > >>> + if (n == 0) > > >>> > > >> > > >> What about using unlikely here? > > >> > > > > > > Unless there is a measurable performance increase by adding in > likely/unlikely > > > I'd suggest avoiding it's use. In general, likely/unlikely should only > be used > > > for things like catestrophic errors because the penalty for taking the > unlikely > > > leg of the code can be quite severe. For normal stuff, where the code > nearly > > > always goes one way in the branch but occasionally goes the other, the > hardware > > > branch predictors generally do a good enough job. > > > > Do you mean using likely/unlikely could be worst than not using it > > in this case? > > > > To me, using unlikely here is not a bad idea: it shows to the compiler > > and to the reader of the code that is case is not the usual case. > > It would be nice to have a guideline section about likely/unlikely in > doc/guides/contributing/design.rst > > Bruce gave a talk at Dublin about this kind of things. > I'm sure he could contribute more design guidelines ;) > There is a small explanation in the section "Branch Prediction" of doc/guides/contributing/coding_style.rst, but I do not know if that is enough to understand when to use them. I've made a fast check and there are many PMDs that use them to check if number of packets is zero in the transmission function.