From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-f180.google.com (mail-ua0-f180.google.com [209.85.217.180]) by dpdk.org (Postfix) with ESMTP id 19AD2DE3 for ; Fri, 13 Jan 2017 12:17:52 +0100 (CET) Received: by mail-ua0-f180.google.com with SMTP id 96so34482928uaq.3 for ; Fri, 13 Jan 2017 03:17:52 -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=AXCZFm0it4oTPDwusudFtYUNTFhrzS2/KuccmShrl9UI2bR59NCWk6pXDzDPM8nzXU BYVHDtAFBQQrRi7SIqI5Kf9XEsZpb8bDoWN3X43SWYc8GYKb6bJCVqxQ2fjE0To1PKj+ Ioe50V3UsB6cxLBjl1R9AHJVljxj8g1NnefiLr5L9KQzm/MqvOmCtTC5hqHcTV4FQAPs h6VKXMgGjqshVOFaHrhV2wr1WfXXPXv0WFvyA2t1oG8rtefs9ZlRLx3RMHkfcZawIdq9 yEwRG41pAw/Ihm0wx/IrY9Glj8nRkoaKYTaIWYlivD4yPWRpS9Ixx1UEhdTAJ3d0PScj AGUA== X-Gm-Message-State: AIkVDXIDsNSVtGhH4tDVqhW6HBNdrToqH/EpqUDizUv4d6NEXcnRiauh1b7a1R6e3a+CNfYXFXrP+T53Xfw1S6Om 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-dev] [dpdk-users] IGB_UIO: PCI Resources Management 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: Fri, 13 Jan 2017 11:17:53 -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 >