From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas.monjalon@6wind.com>
Received: from mail-wr0-f181.google.com (mail-wr0-f181.google.com
 [209.85.128.181]) by dpdk.org (Postfix) with ESMTP id E2C5237AF
 for <dev@dpdk.org>; Thu, 30 Mar 2017 22:22:54 +0200 (CEST)
Received: by mail-wr0-f181.google.com with SMTP id l43so78272994wre.1
 for <dev@dpdk.org>; Thu, 30 Mar 2017 13:22:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=6wind-com.20150623.gappssmtp.com; s=20150623;
 h=from:to:cc:subject:date:message-id:user-agent:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=CftCfIbxFj+2/FtYZsiIkrh9iBU2KZdhecRPaov4HyM=;
 b=pQcc3b+FQ8O3RR8uMVXqsSv2PF3vole5CWOfmiklUjA1547F5CP+kJ0EByOviGG/ii
 oYn7xJzstkEjUz23vfOrRAbxL5CqMU57CGn6Xose6KvmfbK8jgTioz/ZxuaQIFqDueOk
 xYbdxn0ZyOQdaJlQC/96Qyu29f5aJoat/stwS/SdyU+Qv3zO/m85Rjzf94t2s3iKAZ19
 sIicV90RvelVUgsBYcXoa0whiJOIocq8qojmsJg5bkKoBhGopBRdiNor0LBWOVZ6wyUo
 /VAFwldbolSEPBOXfr+gFEWtg+dvF0ABvVjDCdEcAlLApcSum91ZrQoSZP+v0hYJpc19
 0Elg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent
 :in-reply-to:references:mime-version:content-transfer-encoding;
 bh=CftCfIbxFj+2/FtYZsiIkrh9iBU2KZdhecRPaov4HyM=;
 b=r19WwT+cfORwammxKbMYFdBK6ecxaa41QXaOHKADzYsy5tzhhM6slSzuYH03agyH9g
 OMkkCkwdxvvBmK98aa3gU297qD4cZTdsEhs+9USgvWou0oVszkJM+9X044ZcNZKnF4bV
 M/SBZVNpu+VcfQGc2uXeeqNByo1z4Twpb9JNC7GciFQ7VIzqwvQMztXLOHr9QdW7Iooj
 zJvPmCPC9wzn6e1sYROQsoP+8b4ZUJvwLD/PmIz5dkegQKTDQECxjGlu0TE+c3sxi2CH
 r47KzGfVL/AYHmCJJYs++M44lDy7mrhUFuRtQJTR7gLjU3i2bdczy9tCR8C7smmJvGTR
 QRMw==
X-Gm-Message-State: AFeK/H02uunastzrR7+OUPeWafdmjZFJLbVPMgcbgpf/yJses0JxvDjg0qTSypZDtdiJ4IvE
X-Received: by 10.28.61.198 with SMTP id k189mr42564wma.71.1490905374727;
 Thu, 30 Mar 2017 13:22:54 -0700 (PDT)
Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184])
 by smtp.gmail.com with ESMTPSA id 198sm179138wmn.30.2017.03.30.13.22.53
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Thu, 30 Mar 2017 13:22:54 -0700 (PDT)
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Jianfeng Tan <jianfeng.tan@intel.com>, ferruh.yigit@intel.com
Cc: dev@dpdk.org, stephen@networkplumber.org, jing.d.chen@intel.com
Date: Thu, 30 Mar 2017 22:22:53 +0200
Message-ID: <1729096.OcIPJKQlaJ@xps13>
User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; )
In-Reply-To: <1480697146-118038-1-git-send-email-jianfeng.tan@intel.com>
References: <1480696111-116651-1-git-send-email-jianfeng.tan@intel.com>
 <1480697146-118038-1-git-send-email-jianfeng.tan@intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-dev] [PATCH] igb_uio: stop device when closing /dev/uioX
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Mar 2017 20:22:55 -0000

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?

> 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.tan@intel.com>