On 1/19/2017 11:59 PM, 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; 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?
igb_uio is based on UIO framework to do iomem and ioport mapping, and
it's done once in probe. If we do pci_disable_device() in release(),
iomem/ioport mapping will be missing. And I did not figure out a way to
do the iomem/ioport remapping in open() (may be we can check how
vfio-pci succeeds to do this).
2- If we keep pci_enable_device() in probe() can this prevent moving
registering/freeing interrupts in open()/release()
Yes. But then how can we stop a device in release()?
3- And is pci_disable_device() done in release is enough to stop NIC DMA
to access memory?
To find out the answer, we can also use vfio-pci as a reference. Please
refer to vfio_pci_release().
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?
After calling pci_disable_device() in first uio_info->release,
iomem/ioport remap is missing. So my original idea is to let DPDK
initialization not depends on this igb_uio's sysfs files, instead use
the info what pci bus driver provides.
Thanks,
Jianfeng
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
