From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id D56925688 for ; Tue, 13 Jun 2017 09:03:57 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 34CE820B47; Tue, 13 Jun 2017 03:03:57 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 13 Jun 2017 03:03:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=ACoDRQ8LZ6cYj5r 3pFj0gDPE+2WMHyQBASBJcCZjS6A=; b=mrmEdvqsiML7FNc6WOyvOba/XHo62Ev Rh8y3FzQRpepY4fTGXKcfViQZS3RyOWIYV1FKSbV8od95vuZlO9WRImms2/Ww/YS i93k+jZIsVQA/nCLstyjeB977FnleFE/fUuSgzCFqQeEVwH93yHTz6z6qY1smbQY yIhlDLIkENrM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=ACoDRQ8LZ6cYj5r3pFj0gDPE+2WMHyQBASBJcCZjS6A=; b=mwiOFwd/ H2fFURuF0wb4Yjo7NPpJWy+h9yGDFhByC90XHdwj7H/n0nbY1VQls3/VbkII95b9 k9n+iiJUZWRNOQ14ewkjMpGKD3KZWdpdUbowHZ5XVlNYhMH7KuRAb/s6TIMskDGB +s9RKuiR3dTMKhiu41Fho0OFC2+C/P+IXwo3keI5MaGtd/Jqa0hbpvodWBLAIPzX of7RKFOdhjOUhFDRjfDInRA0+KPeSY3SKOKUOF09TldE2SgvKGyAQYswhRyCpM1n z+jOC7QgFthh21F8VTUrn0gVLb2bbxapBTNT0kaN7ORqatHvoWVfOxNdY9W7fvSU 9YEzVqthXMHLWw== X-ME-Sender: X-Sasl-enc: BXo+FKER2yinN9EGxdOZylEeHtjZ9LGxNqv8vsGtMCWC 1497337436 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id D8A437E8E5; Tue, 13 Jun 2017 03:03:56 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Cc: dev@dpdk.org, ferruh.yigit@intel.com Date: Tue, 13 Jun 2017 09:03:56 +0200 Message-ID: <1987640.XeQgTMmFpU@xps> In-Reply-To: <20170613044333.GA5794@jerin> References: <20170608114414.8787-1-jerin.jacob@caviumnetworks.com> <11032075.7h2FW7WDNx@xps> <20170613044333.GA5794@jerin> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 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: Tue, 13 Jun 2017 07:03:58 -0000 13/06/2017 06:43, Jerin Jacob: > -----Original Message----- > > Date: Mon, 12 Jun 2017 18:21:33 +0200 > > From: Thomas Monjalon > > To: Jerin Jacob > > Cc: dev@dpdk.org, ferruh.yigit@intel.com > > Subject: Re: [dpdk-dev] [PATCH v3 1/2] eal/pci: introduce a PCI driver flag > > > > 09/06/2017 12:27, Jerin Jacob: > > > 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. > > > > > > Suggested-by: Ferruh Yigit > > > Signed-off-by: Jerin Jacob > > [...] > > > --- a/lib/librte_eal/common/eal_common_pci.c > > > +++ b/lib/librte_eal/common/eal_common_pci.c > > > @@ -221,7 +221,12 @@ rte_pci_probe_one_driver(struct rte_pci_driver *dr, > > > ret = dr->probe(dr, dev); > > > if (ret) { > > > 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 device is unsupported and > > > + * driver needs mapped resources. > > > + */ > > > + !(ret > 0 && > > > + (dr->drv_flags & RTE_PCI_DRV_KEEP_MAPPED_RES))) > > > rte_pci_unmap_device(dev); > > > } > > > > > > --- a/lib/librte_eal/common/include/rte_pci.h > > > +++ b/lib/librte_eal/common/include/rte_pci.h > > > +/** Device driver needs to keep mapped resources if unsupported dev detected */ > > > +#define RTE_PCI_DRV_KEEP_MAPPED_RES 0x0020 > > > > If I understand well, you want to map resources but not probe it? > > Yes. > > > Shouldn't it be less hacky to probe it as a (new) null class? > > The Vendor and Class ID is same for those device too so we need to map > the PCI bar and have access to know the class of device. If you are concerned about > if it an common code change, My first version was without common code change. > http://dpdk.org/dev/patchwork/patch/24983/ > > Ferruh would like to have flag scheme, I think it make sense for > PMD maintenance perspective. Yes My idea was to have a new class of device interface to reserve those resources, so the probe function would succeed. Do you think it would be a good idea?