From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B0360A0598; Tue, 21 Apr 2020 17:18:25 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DF6401D421; Tue, 21 Apr 2020 17:18:24 +0200 (CEST) Received: from relay11.mail.gandi.net (relay11.mail.gandi.net [217.70.178.231]) by dpdk.org (Postfix) with ESMTP id 9816F1D41F for ; Tue, 21 Apr 2020 17:18:23 +0200 (CEST) Received: from u256.net (lfbn-idf2-1-566-132.w86-246.abo.wanadoo.fr [86.246.31.132]) (Authenticated sender: grive@u256.net) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 88D7110000E; Tue, 21 Apr 2020 15:18:22 +0000 (UTC) Date: Tue, 21 Apr 2020 17:18:17 +0200 From: =?utf-8?Q?Ga=C3=ABtan?= Rivet To: Sunil Kumar Kori Cc: stephen@networkplumber.org, david.marchand@redhat.com, jerinj@marvell.com, dev@dpdk.org Message-ID: <20200421151817.pfcktwfl72mgiuyk@u256.net> References: <20200407092856.554-1-skori@marvell.com> <20200420065554.20138-1-skori@marvell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200420065554.20138-1-skori@marvell.com> Subject: Re: [dpdk-dev] [PATCH v3 1/1] bus/pci: optimise scanning with whitelist/blacklist 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 20/04/20 12:25 +0530, Sunil Kumar Kori wrote: > rte_bus_scan API scans all the available PCI devices irrespective of white > or black listing parameters then further devices are probed based on white > or black listing parameters. So unnecessary CPU cycles are wasted during > rte_pci_scan. > > For Octeontx2 platform with core frequency 2.4 Ghz, rte_bus_scan consumes > around 26ms to scan around 90 PCI devices but all may not be used by the > application. So for the application which uses 2 NICs, rte_bus_scan > consumes few microseconds and rest time is saved with this patch. > Hi Sunil, The PCI bus was written at first with the understanding that all PCI devices were scanned and made available on the bus -- the probe will filter afterward. Device hotplug and iteration were written with this in mind. Changing this principle might have unintended consequences in other EAL parts. I'm not fundamentally against it, but it is not how buses are currently designed in DPDK. To me, a one-time 26ms gain is not enough justification to change this principle. How problematic is this for you? Do you encounter specific issues due to this delay? Thanks, -- Gaëtan