From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 534BCA32A2 for ; Thu, 24 Oct 2019 17:35:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D3C251EB64; Thu, 24 Oct 2019 17:35:05 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 415111EB63 for ; Thu, 24 Oct 2019 17:35:04 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A451222189; Thu, 24 Oct 2019 11:35:03 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 24 Oct 2019 11:35:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=YohxSFatKxnQz8RO9g6J7ZIIWm+JarWy5QCJsOrUSic=; b=GIKskM5Nspnr NPcyKLlM+4qcWosor4ou5WZ2hpRy0Vr6BCjSrPyprIg+2a/c4zae+FTKLwqWvwDd KAqEKz3jiyNImW7wOJboXWouLCfurAdqDV9cuQtsVrPKUiPnmIGBXv0jSz01oLup 55x71ajHCZYUGLWLDCcnttQdgvkPjqA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=YohxSFatKxnQz8RO9g6J7ZIIWm+JarWy5QCJsOrUS ic=; b=b61JByijQOPrr8DKNFBhuyIauUKr2vYQLhrvWr25VCuanncGxQVpILm8W qB62fyR+moVP/9BaKVX+H+1NRN7R8L8Ov6RZk8UBdlQmLlr6oQCl2QKQthc7JMYl 2yqpF8Go/W9dxLG4V2TpGJA2stnOu/RH3g5YpFeBLyEv1Taj8nIcx8BtnRd/jT4G /t0viybc5v6iDgygGq19jNJxA8YFp2Ld0tx1wLJNEyXUicMFxymBTwzJLe/CjgA0 eRQM14aegfq9ho7Q1c6NBgsPVjPVd6CcS2rT78MHm474PE7doC994r7VGT/kd+uu 0J5YiGZKHtTuHBvUHRvypuner94vQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrledugdeklecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 59409D60066; Thu, 24 Oct 2019 11:35:01 -0400 (EDT) From: Thomas Monjalon To: Andrew Rybchenko Cc: dev@dpdk.org, Ori Kam , Ferruh Yigit , "jingjing.wu@intel.com" , "stephen@networkplumber.org" Date: Thu, 24 Oct 2019 17:34:59 +0200 Message-ID: <7486204.JcRLTtQae7@xps> In-Reply-To: <30020504-28c6-0872-77e8-a1eb6d6a134c@solarflare.com> References: <1569479349-36962-1-git-send-email-orika@mellanox.com> <2066428.hBRGAZJfpI@xps> <30020504-28c6-0872-77e8-a1eb6d6a134c@solarflare.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v5 02/15] ethdev: add support for hairpin queue X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 24/10/2019 17:30, Andrew Rybchenko: > On 10/24/19 6:17 PM, Thomas Monjalon wrote: > > 24/10/2019 16:47, Andrew Rybchenko: > >> On 10/24/19 11:29 AM, Ori Kam wrote: > >>> Hi Andrew, > >>> > >>> When writing the new function I thought about using bool, but > >>> I decided against it for the following reasons: > >>> 1. There is no use of bool any where in the code, and there is not special reason to add it now. > >> rte_ethdev.c includes stdbool.h and uses bool > >> > >>> 2. Other functions of this kind already returns int. for example (rte_eth_dev_is_valid_port / rte_eth_is_valid_owner_id) > > I agree with Ori here for 2 reasons: > > 1. It is better to be consistent in the API > > 2. I remember having some issues with some drivers when introducing stdbool in the API. > > > > I think it may be nice to convert all such API to bool in one patch, > > and check if there are some remaining issues with bool usage in drivers or with PPC. > > But I suggest to do such API change in DPDK 20.11. > > OK, no problem. Does it prevent to avoid comparison == 1? Just to > avoid changes in these lines in the future. Yes probably better to avoid explicit comparison, but prefer boolean operator (!).