From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id DB8E97CB9 for ; Wed, 24 May 2017 13:22:13 +0200 (CEST) Received: by mail-wm0-f45.google.com with SMTP id 7so60617787wmo.1 for ; Wed, 24 May 2017 04:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=weka.io; s=google; h=from:to:cc:subject:date:message-id:organization:mime-version :content-transfer-encoding; bh=+4IRJajTWwa0DtRTAlSkp10Y0DzSO9fWU70WWmf2qz0=; b=vei941d+Y4ax/S8gjVtaSmg/e4mwLXzaxiDmrf/30Gh7Ae406Dok5CgBJy0sjjQm1f nGU9LWS42UoXMy1Un+oo4vTvWYbPDBaFLoOLx9TKoTR1A6ZHcX//Uuhpo/RGQzHVvPGR dtGN9V2F0A+NHgnX3q8VVrhfuE9xZPimkcqoQ= 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:organization :mime-version:content-transfer-encoding; bh=+4IRJajTWwa0DtRTAlSkp10Y0DzSO9fWU70WWmf2qz0=; b=GXxYIwcVt22PCwmYJMH08ZR1msm6D6ANeY5dF5c7OOamGTIh5jmtAocMvoPGHJ5AXu +cl2ZS1/1UVpKsW1rm4ZCKoqfq9NFaBeEOT5C2n9C+7qreoE5JQgB+UhNeMQnKctJJw5 UVrWJog74IO2raUvjghKpzn2By3kdHe2GQiHy6EOb9HH6I0ujDC4IYJxzVMyAdlafGcb K0u9FO/r9tIbQOFexavJnbfdw3YRtjvHNBSe2wCHHP7TjJw5i/ZVFsQD87ivkpC7RMKr PXI04Ne3HKeVuff1GgDFIfSGkc6N8vtnOAt9egzNFGiEUxbEJsk9cuBkeZnKLuLUf35I k3OA== X-Gm-Message-State: AODbwcDuVrA31MgTTpyx08kZNt0IrAgP7lKT1VofXNnQlkxxAnxJkFWk kzRAmJ+ewALmeh+q X-Received: by 10.28.38.68 with SMTP id m65mr6198890wmm.25.1495624933374; Wed, 24 May 2017 04:22:13 -0700 (PDT) Received: from polaris.localnet (bzq-82-81-85-138.red.bezeqint.net. [82.81.85.138]) by smtp.gmail.com with ESMTPSA id e83sm5465837wmc.28.2017.05.24.04.22.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2017 04:22:12 -0700 (PDT) From: Gregory Etelson To: dev@dpdk.org Cc: Ferruh Yigit , Qi Zhang , Wenzhuo Lu Date: Wed, 24 May 2017 14:22:11 +0300 Message-ID: <106841857.Z7q1jSDIte@polaris> Organization: Weka.IO MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] i40e igb_uio: reset pci on process exit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 11:22:14 -0000 Hello, My tests show if DPDK process attached to i40e VF through igb_uio exists without calling rte_eth_dev_close() then new instance attached to that VF could experience IO failures. I came up with the following patch to ensure igb_uio will always reset PCI on process exit. However, I would like to hear experts opinion to be sure __pci_reset_function resets i40e VF properly. Thank you. Regards, Gregory diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c index b9d427c..7d7ff9d 100644 --- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c +++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c @@ -170,6 +170,19 @@ struct rte_uio_pci_dev { return IRQ_HANDLED; } +static int +igbuio_pci_release(struct uio_info *info, struct inode *inode) +{ + int ret; + struct rte_uio_pci_dev *udev = info->priv; + struct pci_dev *dev = udev->pdev; + ret = __pci_reset_function(dev); + dev_info(&dev->dev, "pci_reset_function %s \n", + ret == 0 ? "succeded" : "failed"); + return 0; +} + + #ifdef CONFIG_XEN_DOM0 static int igbuio_dom0_mmap_phys(struct uio_info *info, struct vm_area_struct *vma) @@ -372,6 +385,7 @@ struct rte_uio_pci_dev { udev->info.version = "0.1"; udev->info.handler = igbuio_pci_irqhandler; udev->info.irqcontrol = igbuio_pci_irqcontrol; + udev->info.release = igbuio_pci_release; #ifdef CONFIG_XEN_DOM0 /* check if the driver run on Xen Dom0 */ if (xen_initial_domain())