From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 16F3028F3 for ; Thu, 8 Jun 2017 21:44:19 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jun 2017 12:44:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,315,1493708400"; d="scan'208";a="97237385" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.91]) ([10.237.220.91]) by orsmga002.jf.intel.com with ESMTP; 08 Jun 2017 12:44:17 -0700 To: Jerin Jacob Cc: dev@dpdk.org, thomas@monjalon.net References: <20170601130530.11443-1-jerin.jacob@caviumnetworks.com> <20170608114414.8787-1-jerin.jacob@caviumnetworks.com> <20170608171557.GB15360@jerin> From: Ferruh Yigit Message-ID: <979ff41d-8866-6bab-d102-74c605fb7e03@intel.com> Date: Thu, 8 Jun 2017 20:44:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170608171557.GB15360@jerin> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v2 1/2] eal/pci: introduce a PCI driver flag 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: Thu, 08 Jun 2017 19:44:20 -0000 On 6/8/2017 6:15 PM, Jerin Jacob wrote: > -----Original Message----- >> Date: Thu, 8 Jun 2017 15:40:33 +0100 >> From: Ferruh Yigit >> To: Jerin Jacob , dev@dpdk.org >> CC: thomas@monjalon.net >> Subject: Re: [dpdk-dev] [PATCH v2 1/2] eal/pci: introduce a PCI driver flag >> User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 >> Thunderbird/52.1.1 >> >> On 6/8/2017 12:44 PM, Jerin Jacob wrote: >>> Some ethdev devices like nicvf thunderx PMD need special treatment for >>> Secondary queue set(SQS) PCIe VF devices, where, it expects to not unmap >>> or free the memory without registering the ethdev subsystem. >>> >>> Introducing a new RTE_PCI_DRV_KEEP_MAPPED_RES >>> PCI driver flag to request PCI subsystem to not unmap the mapped PCI >>> resources(PCI BAR address) if unsupported device detected. >>> >>> Signed-off-by: Jerin Jacob >> >> <...> >> >>> @@ -235,6 +240,7 @@ rte_pci_probe_one_driver(struct rte_pci_driver *dr, >>> static int >>> rte_pci_detach_dev(struct rte_pci_device *dev) >>> { >>> + int ret = 0; >>> struct rte_pci_addr *loc; >>> struct rte_pci_driver *dr; >>> >>> @@ -251,13 +257,18 @@ rte_pci_detach_dev(struct rte_pci_device *dev) >>> RTE_LOG(DEBUG, EAL, " remove driver: %x:%x %s\n", dev->id.vendor_id, >>> dev->id.device_id, dr->driver.name); >>> >>> - if (dr->remove && (dr->remove(dev) < 0)) >>> - return -1; /* negative value is an error */ >>> + if (dr->remove) { >>> + ret = dr->remove(dev); >>> + if (ret < 0) >>> + return -1; /* negative value is an error */ >>> + } >>> >>> /* clear driver structure */ >>> dev->driver = NULL; >>> >>> - if (dr->drv_flags & RTE_PCI_DRV_NEED_MAPPING) >>> + if ((dr->drv_flags & RTE_PCI_DRV_NEED_MAPPING) && >>> + /* Don't unmap if dev is unsupported and it needs mapped resources */ >>> + !(ret > 0 && (dr->drv_flags & RTE_PCI_DRV_KEEP_MAPPED_RES))) >> >> Why it is required to keep mapping during detach? > > To keep symmetrical with other(on probe) unmap change. This will > activated only when PMD returns the positive number on remove() so PMD > has control over it. The existing use case, We cannot just detach a single > VF(one SQS VF is _not_ one ethdev port i.e one ethdev port consists of > multiple VFs) so we need control on when to unmap those BARs. For generic eal, there is an explicit request to detach the device, I am not sure about returning success but not releasing the resources based on PMD flag. How this will work with hotplug? And specific to your case, -thanks for clarification, since no eth_dev created for SQS VF, rte_eth_dev_pci_generic_remove() won't be useful but assuming you have implemented your remove(), can it be possible to detect SQS VF and act accordingly, or just return error perhaps if you cannot detach that VF? > >> >>> /* unmap resources for devices that use igb_uio */ >>> rte_pci_unmap_device(dev); >>> >> >> <...> >>