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; us...@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-boun...@dpdk.org] On Behalf Of Ferruh Yigit >>>> Sent: Thursday, January 12, 2017 8:22 PM >>>> To: Alejandro Lucero >>>> Cc: Gregory Etelson; dev; us...@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.yi...@intel.com >>>>> <mailto:ferruh.yi...@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.
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 >
