From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) by dpdk.org (Postfix) with ESMTP id 0C1C81F1C for ; Mon, 29 Oct 2018 15:35:16 +0100 (CET) Received: by mail-ed1-f67.google.com with SMTP id y20-v6so7491037eds.10 for ; Mon, 29 Oct 2018 07:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MXhDRf4eH4LJWmfG4eC+fvSvaP1FYtl9YONc1+JO+I8=; b=a4YcQH6vZT9teCPNBkSUqSdXN/IJNNyRSXP3nMsJUp7jmEyY6AzFVnScmvkpAhipEM MhNPOrtbqJoV2eC9TJE/C5H8XxuwlEKWCbEs/CTgMC9NUBlZnOTejCUE3yW2Kh1nMVHW Ql3aKjqw49WD3r7c+bAn9/1H6ixg85euQ5Lbv0p9fy9rztXMbzUY+ZdOerrdgQyUZBgs HszioxJolNWRoljvPAy5V5MLT2oGQKN8AcouqyqVc63PcG7UZvrlecZwJdNxPFFuKVeG US4woHE49ZoeSKUHnPdUGwuNdTDoBAUJtKBbfmivM9/a0H3XBn88EDJSBAa9LePAQcA4 nZYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MXhDRf4eH4LJWmfG4eC+fvSvaP1FYtl9YONc1+JO+I8=; b=OXcchelulMjIgA4PsLULKy9oCH6yvao5Wyh8Jgg5E/kPih8KOH7uPm26R+O36OM5/u jLkRej8LQejkDkJzcX1xKbgbpqiJdByxL1N9iF3JVIOUH8c0ZhMc3j8XU2LRTn3ydFKP uftGR48Rm9BuiEAftGCbjstiahrHPRKJdDkaeO1wLLCrLuNQ9Gt8uC+8LElYRdwr/oMW Jkn7RmTjK2J15n0NZyJSsIKDymCR3RHS3PW1xyAoc2a4479898+We1+1puuKw4MG4O0q 1q+JGukXGjSgjNexaEJcFl/7UWGOr4n3/oVzi8Ba9mXpRD8MapT3rzoOLG2goNhMtRp1 DmrQ== X-Gm-Message-State: AGRZ1gLHQPqhAan4bWPJfHPnJRiFpL3fdIVNvHrXrhUf5bLerraT8i4s /yjdFganDTbPunVlsdGckPTaIJ/7Hoc0g/lLpeKtow== X-Google-Smtp-Source: AJdET5c5k7wphuAwvRee3fj4jAtvklae20CBzU/+CLx3XRsbO9X+d5QxF0HIGv9GbXyAMKIMlHxxn/mb9ph78b5cgDc= X-Received: by 2002:a50:9386:: with SMTP id o6-v6mr14230728eda.248.1540823715726; Mon, 29 Oct 2018 07:35:15 -0700 (PDT) MIME-Version: 1.0 References: <1538743527-8285-1-git-send-email-alejandro.lucero@netronome.com> <2DBBFF226F7CF64BAFCA79B681719D954502B94F@shsmsx102.ccr.corp.intel.com> <3483377.PMXnpSGLS9@xps> In-Reply-To: <3483377.PMXnpSGLS9@xps> From: Alejandro Lucero Date: Mon, 29 Oct 2018 14:35:04 +0000 Message-ID: To: Thomas Monjalon Cc: lei.a.yao@intel.com, dev , "Xu, Qian Q" , xueqin.lin@intel.com, "Burakov, Anatoly" , Ferruh Yigit Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 14:35:16 -0000 On Mon, Oct 29, 2018 at 2:18 PM Thomas Monjalon wrote: > 29/10/2018 14:40, Alejandro Lucero: > > On Mon, Oct 29, 2018 at 1:18 PM Yao, Lei A wrote: > > > *From:* Alejandro Lucero [mailto:alejandro.lucero@netronome.com] > > > On Mon, Oct 29, 2018 at 11:46 AM Thomas Monjalon > > > wrote: > > > > > > 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. > > > > > > I think once the call to rte_eal_check_dma_mask uses the maskbits > instead > > > of the mask, calling rte_memseg_walk_thread_unsafe avoids the deadlock. > > > > > > Yao, can you try with the attached patch? > > > > > > Hi, Lucero > > > > > > This patch can fix the issue at my side. Thanks a lot > > > for you quick action. > > > > Great! > > > > I will send an official patch with the changes. > > Please, do not forget my other request to better comment functions. > > > Sure. > > I have to say that I tested the patchset, but I think it was where > > legacy_mem was still there and therefore dynamic memory allocation code > not > > used during memory initialization. > > > > There is something that concerns me though. Using > > rte_memseg_walk_thread_unsafe could be a problem under some situations > > although those situations being unlikely. > > > > Usually, calling rte_eal_check_dma_mask happens during initialization. > Then > > it is safe to use the unsafe function for walking memsegs, but with > device > > hotplug and dynamic memory allocation, there exists a potential race > > condition when the primary process is allocating more memory and > > concurrently a device is hotplugged and a secondary process does the > device > > initialization. By now, this is just a problem with the NFP, and the > > potential race condition window really unlikely, but I will work on this > > asap. > > Yes, this is what concerns me. > You can add a comment explaining the unsafe which is not handled. > > I'' do. Thanks! > > > > > 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 > > > > > > > > > > > > > >