On 3/30/2017 9:22 PM, Thomas Monjalon wrote: > 2016-12-02 16:45, Jianfeng Tan: >> Depends-on: http://dpdk.org/dev/patchwork/patch/17493/ > > The above patch is marked as rejected. > Do we want to reject also this patch?
Above patch rejected because it may have backward compatibility issues with the older DPDK (1.8 and older if I remember correct) with newer kernels. Plan was checking if this patch can be updated to remove dependency, and if not accepting above patch. But as far as I can see not worked on it. We may drop this if Jianfeng don't have any plan to work on it. > >> When a DPDK application grab a PCI device, device and driver work >> together to Rx/Tx packets. If the DPDK app crashes or gets killed, >> there's no chance for DPDK driver to stop the device, which means >> rte_eth_dev_stop() will not be called. >> >> This could result in problems. In virtio's case, the device (the >> vhost backend), will keep working. If packets come, the vhost will >> copy them into the vring, which is negotiated with the previous DPDK >> app. But the resources, especially hugepages, are recycled by VM >> kernel. What's worse, the memory could be allocated for other usage, >> and re-written. This leads to an uncertain situation. Like this post >> has reported, https://bugs.launchpad.net/qemu/+bug/1558175, QEMU's >> vhost finds out wrong value, and exits the whole QEMU process. >> >> To make it right, we need to restart (or reset) the device and make >> the device go into the initial state, when uio-generic or igb_uio >> recycles the PCI device. There's a chance in uio framework to disable >> devices when /dev/uioX gets closed. Here we enable the pci device >> in open() hook and disable it in release() hook. >> >> However, if device is not enabled in probe() phase any more, we can >> not register irq in probe() through uio_register_device(). To address >> that, we invoke request_irq() to register callback directly. >> >> Similar change needs to be done in uio-generic driver. And vfio-pci >> seems to have done that already. >> >> Signed-off-by: Jianfeng Tan <jianfeng....@intel.com> >
