From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp5.epfl.ch (smtp5.epfl.ch [128.178.224.8]) by dpdk.org (Postfix) with ESMTP id B3E9FFA3A for ; Thu, 19 Jan 2017 17:09:20 +0100 (CET) Received: (qmail 10690 invoked by uid 107); 19 Jan 2017 16:09:18 -0000 X-Virus-Scanned: ClamAV Received: from icdhcp-1-010.epfl.ch (HELO [128.178.116.10]) (128.178.116.10) (TLS, DHE-RSA-AES256-SHA cipher) (authenticated) by mail.epfl.ch (AngelmatoPhylax SMTP proxy) with ESMTPSA; Thu, 19 Jan 2017 17:09:18 +0100 To: Ferruh Yigit , "Tan, Jianfeng" , Alejandro Lucero References: <3355891.l3I590SjcV@polaris> <608e7dfd-5226-3e30-f43b-0fbe01aee16a@intel.com> <7605618f-dc86-3060-473e-aff5545cac72@intel.com> <076f570e-0679-1208-8625-93256796a756@intel.com> Cc: Gregory Etelson , dev , "users@dpdk.org" From: George Prekas Message-ID: Date: Thu, 19 Jan 2017 17:09:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <076f570e-0679-1208-8625-93256796a756@intel.com> X-Mailman-Approved-At: Fri, 20 Jan 2017 11:02:30 +0100 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 19 Jan 2017 16:09:20 -0000 Nice to see that the community is finally interested in this bug. For the record, we have fixed this bug in our project (IX). Check out our kernel module here: https://github.com/ix-project/pcidma I will be interested to know when and how DPDK will resolve this situation so that we can actually use your solution in our project. On 19/01/2017 16:59, Ferruh Yigit wrote: > On 1/13/2017 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 >>>>> > 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. > I thinks implementing uio_info->release and uio_info.open is good idea, > but I have a few questions: > > 1- What is the the dependency to "iomem and ioport mapping" patch? > > 2- If we keep pci_enable_device() in probe() can this prevent moving > registering/freeing interrupts in open()/release() > > 3- And is pci_disable_device() done in release is enough to stop NIC DMA > to access memory? > > > I did a simple test, implemented simple uio_info->release and > uio_info.open, which only does pci_disable_device() and > pci_enable_device(), > but this prevent app receiving packets in its second run, independent > from app terminated gracefully or not. Any idea why this is not working? > > > btw, I can produce the problematic case, as George Prekas described in: > http://dpdk.org/ml/archives/users/2016-September/001026.html > > CC'ed George, since he also seems interested in issue. > >> Thanks, >> Jianfeng >>