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 522A82082 for ; Mon, 5 Nov 2018 01:03:17 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B6D6521C76; Sun, 4 Nov 2018 19:03:16 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 04 Nov 2018 19:03:16 -0500 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=Zy7lfISL5rUbWldlcul6J2ZMkfIbevUnwzihlRlCdvM=; b=FL6Gz/j8xxlI 7sNemp5Zc6u3wlQgSK2z7da5c1/9O78Eo/k0lvRLr1OnH0naHq5z8RnA6pQVXqZU 8GLpbk2STWAXq7BBX9LsJY23zBZi3uo3eEb7+zpCsyF0qLFpy1crb30FbGmyXl2U O4pNU4yYYplJeH7N1wL1Fpsh613lN74= 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=Zy7lfISL5rUbWldlcul6J2ZMkfIbevUnwzihlRlCd vM=; b=PzOuWqYGY6b5iBkH4bXpW4vK6WfRysx94LQN7qxkxg8KUowdn/VfX3S6W a6NLxssgWvX8UtQcEvdaJ8pxJzcNiCKu9Kj6bp/BFVyDOKkVETepNEgaI7yQvnnG WcGHruytcg7eqaat0CzBYk6yOGH5fQxs3u26YU7N+IM0W8RRL4fqbI9fA40GTkZP L4aq7q99HEDIseXQ2n5fNNj4sbZFyQn92MMP8oZt+b4iqg7F6SPB/NXJsT/wvcK/ O332NJo4koMSFjwk8gO/n+/IVjbZJBjNQrIr41/4/KGGweT4j0xAhy1d74rc97v9 zy7ENifq7IrVj8v6OIwlwDVLz95MA== 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 B9489102E0; Sun, 4 Nov 2018 19:03:15 -0500 (EST) From: Thomas Monjalon To: Alejandro Lucero Cc: dev@dpdk.org, Ferruh Yigit Date: Mon, 05 Nov 2018 01:03:14 +0100 Message-ID: <1581850.6WJm0uvOED@xps> In-Reply-To: <925cecc0-503d-324d-3634-2ec0857ccffc@intel.com> References: <20181101195330.19464-1-alejandro.lucero@netronome.com> <925cecc0-503d-324d-3634-2ec0857ccffc@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 0/7] fix DMA mask check 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, 05 Nov 2018 00:03:18 -0000 02/11/2018 19:38, Ferruh Yigit: > On 11/1/2018 7:53 PM, Alejandro Lucero wrote: > > A patchset sent introducing DMA mask checks has several critical > > issues precluding apps to execute. The patchset was reviewed and > > finally accepted after three versions. Obviously it did not go > > through the proper testing what can be explained, at least from my > > side, due to the big changes to the memory initialization code these > > last months. It turns out the patchset did work with legacy memory > > and I'm afraid that was mainly my testing. > > > > This patchset should solve the main problems reported: > > > > - deadlock duriing initialization > > - segmentation fault with secondary processes > > > > For solving the deadlock, a new API is introduced: > > > > rte_mem_check_dma_mask_safe/unsafe > > > > making the previous rte_mem_check_dma_mask the one those new functions > > end calling. A boolean param is used for calling rte_memseg_walk thread > > safe or thread unsafe. This second option is needed for avoiding the > > deadlock. > > > > For the secondary processes problem, the call to check the dma mask is > > avoided from code being executed before the memory initialization. > > Instead, a new API function, rte_mem_set_dma_mask is introduced, which > > will be used in those cases. The dma mask check is done once the memory > > initialization is completed. > > > > This last change implies the IOVA mode can not be set depending on IOMMU > > hardware limitations, and it is assumed IOVA VA is possible. If the dma > > mask check reports a problem after memory initilization, the error > > message includes now advice for trying with --iova-mode option set to > > pa. > > > > The patchet also includes the dma mask check for legacy memory and the > > no hugepage option. > > > > Finally, all the DMA mask API has been updated for using the same prefix > > than other EAL memory code. > > > > An initial version of this patchset has been tested by Intel DPDK > > Validation team and it seems it solves all the problems reported. This > > final patchset has the same functionality with minor changes. I have > > successfully tested the patchset with my limited testbench. > > > > v2: > > - modify error messages with more descriptive information > > - change safe/unsafe versions for dma check to previous one plus a > > thread_unsafe version. > > - use rte_eal_using_phys_addr instead of getuid > > - fix comments > > - reorder patches > > > > Alejandro Lucero (7): > > mem: fix call to DMA mask check > > mem: use proper prefix > > mem: add function for setting DMA mask > > bus/pci: avoid call to DMA mask check > > mem: modify error message for DMA mask check > > eal/mem: use DMA mask check for legacy memory > > mem: add thread unsafe version for checking DMA mask > > Tested-by: Ferruh Yigit > > Fixing the deadlock issue, and build/per-patch build is good. Applied, thanks