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 2162BFEB for ; Mon, 29 Oct 2018 14:40:54 +0100 (CET) Received: by mail-ed1-f67.google.com with SMTP id v18-v6so7297326edq.13 for ; Mon, 29 Oct 2018 06:40:54 -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=FNJR5pXpWPanJmcJADeUAmAn6gEnNhpTZ+WczUvzuKo=; b=rDMrv0ozVPq9SfTHlJjX3ylLZGsCAIqQ5xk+C3uwT0NT8v7RSHSUwDD8x0xrjAtI8X khsOu2siIRnBAU65GVMZ+5TPpAvsdjqXt01IjnC4l0UUSn2hBWT/8eHBNqHhRRX+SUh+ uCuVakS4J4gmYesHFwSFVivGegtbJfBLolG3DHb4oUX0aeXFqi1VhJhrxJVcfJiqEVdx ngMWcUDH+l40XEfRrReiQdfKVu8+QL5bYE5wHAcptSgMBYrJABnZ12b3LdBnbKPw0/75 xlNWVggQTuLEYuYnyXinW+H3Fbt7GB562A1KJxQQir32ssmzGgfcmipUEMo3Vw1KO6Qj bgIg== 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=FNJR5pXpWPanJmcJADeUAmAn6gEnNhpTZ+WczUvzuKo=; b=gbk0Ic6BJCzggO1oFqalwz0n5sqtb660Tsxv3s4y1tz/+yo5gXd1Gr4wxFHuG/DoYx +UX64yVniUhRnnb3H7wEzosta8R9aCklxfXhwUkYHtJbMXzcap4Bd/7JEadSryS/+kpm a/ILD5ksNHpAK0h0be/v8PPbuY9fBsnkIqxMJ4AJ/SJlWQL99QrWQ2z05EkMk4GG/atz A6cX7Kq2+IMxPjWO/SbkKEkB3XDy6lvURoCI3obH/1qKU2H+OE/XnRdCIiF2jdoaApeV UPTDwj06JSu+5g1gYzZ2AN64Za4k0CoskTpVQmhPCIpgPGtJkX5hzTUaIEGlAbkm+0/7 uQZA== X-Gm-Message-State: AGRZ1gIkNZ6gbQlX467DmN/fZHHDDMoNrVuJGdIVzPWBa7ulvZalQUil P7ysALkMfLNVTEot2FtoFsr30RFu/+cAS+ZR6UBmCw== X-Google-Smtp-Source: AJdET5f+jCsr1g93D9xU0HfqAVA5R3T6k3U/mIJQcG+/DWzRWmWhZ1MRTUijJbJZ6E1+wZy7beLUP/YdTDYKt8Y84Jw= X-Received: by 2002:a17:906:3744:: with SMTP id e4-v6mr5914060ejc.233.1540820453692; Mon, 29 Oct 2018 06:40:53 -0700 (PDT) MIME-Version: 1.0 References: <1538743527-8285-1-git-send-email-alejandro.lucero@netronome.com> <2737161.TvyDVilZt4@xps> <2DBBFF226F7CF64BAFCA79B681719D954502B94F@shsmsx102.ccr.corp.intel.com> In-Reply-To: <2DBBFF226F7CF64BAFCA79B681719D954502B94F@shsmsx102.ccr.corp.intel.com> From: Alejandro Lucero Date: Mon, 29 Oct 2018 13:40:42 +0000 Message-ID: To: lei.a.yao@intel.com Cc: Thomas Monjalon , 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 13:40:54 -0000 On Mon, Oct 29, 2018 at 1:18 PM Yao, Lei A wrote: > > > > > *From:* Alejandro Lucero [mailto:alejandro.lucero@netronome.com] > *Sent:* Monday, October 29, 2018 8:56 PM > *To:* Thomas Monjalon > *Cc:* Yao, Lei A ; dev ; Xu, Qian Q < > qian.q.xu@intel.com>; Lin, Xueqin ; Burakov, > Anatoly ; Yigit, Ferruh > > *Subject:* Re: [dpdk-dev] [PATCH v3 0/6] use IOVAs check based on DMA mask > > > > > > 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. 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. > BRs > > Lei > > > > > 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 > >