From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 1F1B610A3 for ; Mon, 29 Oct 2018 12:46:41 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AAD1F20964; Mon, 29 Oct 2018 07:46:40 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 29 Oct 2018 07:46:40 -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=NpsaTzFWEzJl19OpxASP2mpEwHjIY002CIBHfiyT0aA=; b=BsD98nAmmtho 79BkakqceRFvBi/X0/6cVDEAsk5ldcTPiyGnoUTpDjsvCtGMwB0Ekv2+p9CbsUot 70Z/5GReld2v0U6cefMxtv3/XuYVlWXDBOvxIENtjLkkD5FzOn5ISqXDjQ3DoTU0 iZJna9h5f1MPHJ7T2uc3F5pP6lThC1g= 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=NpsaTzFWEzJl19OpxASP2mpEwHjIY002CIBHfiyT0 aA=; b=t43+NKtoSYQwQs/g/2eVnUMpxxmLlXoXx87urWcNnVSOKc3G90YbWHCXr ziLOtTZiVGmzhzVBp/wL+Qs0nDZz0WylF7uK/uqd2+dFKRO7dj5orsB/hPa6psFL px8/gKkgMwgG2+4huvSEsrxz9WxFrLNuWHPzDHtfA5szL9TNXo0lgkhJNUYeqc9l 3aVb2HVudnLdM6eVAOirE8/k5fyuh0Rg4FDSViDX22KB2MqmwOwAP7ecZjSab4aQ Y5bKQ8jfzxoJJa4DMkyGhWnyTsyoJEdNVzlDaZzQ8PDYqJ11zY2m43ezRpB0fa1g s7aSZnTiKVmzeq5W4wR7/kbFBIGGQ== X-ME-Sender: 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 6515B102E4; Mon, 29 Oct 2018 07:46:39 -0400 (EDT) From: Thomas Monjalon To: Alejandro Lucero Cc: lei.a.yao@intel.com, dev , "Xu, Qian Q" , xueqin.lin@intel.com, "Burakov, Anatoly" , Ferruh Yigit Date: Mon, 29 Oct 2018 12:46:45 +0100 Message-ID: <2737161.TvyDVilZt4@xps> In-Reply-To: References: <1538743527-8285-1-git-send-email-alejandro.lucero@netronome.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 0/6] use IOVAs check based on DMA mask 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: , X-List-Received-Date: Mon, 29 Oct 2018 11:46:41 -0000 29/10/2018 12:39, Alejandro Lucero: > I got a patch that solves a bug when calling rte_eal_dma_mask using the > mask instead of the maskbits. However, this does not solves the deadlock. The deadlock is a bigger concern I think. > Interestingly, the problem looks like a compiler one. Calling > rte_memseg_walk does not return when calling inside rt_eal_dma_mask, but if > you modify the call like this: > > - if (rte_memseg_walk(check_iova, &mask)) > + if (!rte_memseg_walk(check_iova, &mask)) > > it works, although the value returned to the invoker changes, of course. > But the point here is it should be the same behaviour when calling > rte_memseg_walk than before and it is not. Anyway, the coding style requires to save the return value in a variable, instead of nesting the call in an "if" condition. And the "if" check should be explicitly != 0 because it is not a real boolean. PS: please do not top post and avoid HTML emails, thanks