From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-f170.google.com (mail-ua0-f170.google.com [209.85.217.170]) by dpdk.org (Postfix) with ESMTP id E6814558D for ; Fri, 13 Jan 2017 12:19:11 +0100 (CET) Received: by mail-ua0-f170.google.com with SMTP id y9so34763659uae.2 for ; Fri, 13 Jan 2017 03:19:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WovOBD2sTL1Fg/84mAupAHlwRTz1WcHJZZdWqBc0Yu4=; b=vErBdXPNwl5SUQ1GaCA0g7ZEm+VwrpJBP+Xgu8yXPte4RmthxDvvxR8iBCgDeqbhT4 s3pxGYtg2FOf2FL1DVW/ath7OIOzorN1gTbpVlH4bKSBMv77AAGTlF2uS7BjCzCKGlRP KxiX7siIvEToyhQy2UyE80aCE2ghLBoI6m9Y7HnmGGUY1RfUvfJrydeJdj+U3c9cZrWw 9ijhQ3akw4AKjQ//lYp6La56aEKF/WjjBsgZjH6YDDjRCOrxGIAFNsunrLfwkBJ1lwz0 Syy0JSSb13CvEZbH9q+VRcdoFT9lba44FJvgM/+6bWaodabAZf7bY3vG64KR4NLgDZ49 o8ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WovOBD2sTL1Fg/84mAupAHlwRTz1WcHJZZdWqBc0Yu4=; b=qwIcBnVfz/3EH06dOj4OnK+LvvBHhCD3GfnMwDWQyr/gYkG1ZNHU16Ec41iamKnjFL v3hAgg3sENL7gwOlNidB0W4xopiToLE+dRReCruE2v+gr7i682OXdOwXyCV3LepNrmTl K6R5chfY+5QWXsjypb5HFa8bAky4qQRzPRMSkjzSPNCJEEBWpqYxDjtGPjdKspqacWr8 QBm2fpUtvt1k6IjnjYnDrMCQW/BJdt8Y8uDu3vD9OM2afCDt6P6Vi3wzcfxYRM2GQQcq +4/X87+tC1Z5bFrs6B74ZVCGtKR3XojiUrf88k1R0I1JDHX4GnLM1dDtb7unbShhn1H7 GXpA== X-Gm-Message-State: AIkVDXLLnFAXzNDrxX+bDgnGIfBsYf3xivnPO4cMiWd9fmbHUEA3Gg6+/QdRDc82gYnRmGfW9tz07sESnCaMPq18 X-Received: by 10.176.6.130 with SMTP id g2mr9189687uag.91.1484305853741; Fri, 13 Jan 2017 03:10:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.146.141 with HTTP; Fri, 13 Jan 2017 03:10:53 -0800 (PST) In-Reply-To: References: <3355891.l3I590SjcV@polaris> <608e7dfd-5226-3e30-f43b-0fbe01aee16a@intel.com> <7605618f-dc86-3060-473e-aff5545cac72@intel.com> From: Alejandro Lucero Date: Fri, 13 Jan 2017 11:10:53 +0000 Message-ID: To: "Tan, Jianfeng" Cc: "Yigit, Ferruh" , Gregory Etelson , dev , "users@dpdk.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] [dpdk-dev] IGB_UIO: PCI Resources Management X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 11:19:12 -0000 I completely misread the patch, and I wrongly thought that code was linked to module removal, but I see this is not about that, but about releasing the /dev/uio file calling release function, what is done by the kernel when the process exits. So yes, the patch avoids the problem I talked about. However, calling that specific ixgbe driver function will break other devices relying on igb_uio. What about implementing a notifier chain for this? The igb_uio code would be agnostic and each interested driver, like ixgbe or nfp_net, could execute the specific port close code when the notifier chain triggers. On Fri, Jan 13, 2017 at 5:33 AM, Tan, Jianfeng wrote: > > > > -----Original Message----- > > From: Yigit, Ferruh > > Sent: Friday, January 13, 2017 10:05 AM > > To: Tan, Jianfeng; Alejandro Lucero > > Cc: Gregory Etelson; dev; users@dpdk.org > > Subject: Re: [dpdk-users] [dpdk-dev] IGB_UIO: PCI Resources Management > > > > On 1/13/2017 1:51 AM, Tan, Jianfeng wrote: > > > > > > > > >> -----Original Message----- > > >> From: users [mailto:users-bounces@dpdk.org] On Behalf Of Ferruh Yigit > > >> Sent: Thursday, January 12, 2017 8:22 PM > > >> To: Alejandro Lucero > > >> Cc: Gregory Etelson; dev; users@dpdk.org > > >> Subject: Re: [dpdk-users] [dpdk-dev] IGB_UIO: PCI Resources > > Management > > >> > > >> On 1/12/2017 12:12 PM, Alejandro Lucero wrote: > > >>> > > >>> > > >>> On Thu, Jan 12, 2017 at 11:55 AM, Ferruh Yigit < > ferruh.yigit@intel.com > > >>> > wrote: > > >>> > > >>> On 12/9/2016 8:54 AM, Gregory Etelson wrote: > > >>> > Hello, > > >>> > > > >>> > IGB_UIO driver does not close port PCI activities after DPDK > process > > >> exits. > > >>> > DPDK API provides rte_eth_dev_close() to manage port PCI, > > >>> > but it can be skipped if process receives SIGKILL signal > > >>> > > >>> I guess I understand the problem. > > >>> > > >>> > > >>> This is a known problem, but it is not just a UIO problem, and this > > >>> patch does not solve it, maybe it just solves part of it. > > >>> > > >>> In fact, a DPDK program crashing could imply the NIC DMAing after > that > > >>> and after that memory was assigned to another program. > > >> > > >> Yes. > > >> Can there be a way to stop NIC DMA, (or prevent it access to mem > > >> anymore) when app crashes? > > >> I think that is what this patch is looking for. > > > > > > If I understand it correctly, you are looking for this patch? > > > http://dpdk.org/dev/patchwork/patch/17495/ > > > > > > > That is good, thanks Jianfeng, I will check it. > > > > btw, patch's current state is rejected, which is by mistake, it seems I > > confused it with "iomem and ioport mapping" patch, sorry about it, I > > will update its status immediately. > > No problem at all. This patch is rejected as it's based on "iomem and > ioport mapping" patch. As "iomem and ioport mapping" patch has backward > compatibility issue, we need to figure out a way to resubmit this patch > without changing the original "iomem and ioport mapping" in igb_uio. > > Thanks, > Jianfeng >