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 712DFA00C2; Wed, 22 Apr 2020 11:38:37 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 05DCD1D453; Wed, 22 Apr 2020 11:38:37 +0200 (CEST) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by dpdk.org (Postfix) with ESMTP id 42CD41D448 for ; Wed, 22 Apr 2020 11:38:36 +0200 (CEST) X-Originating-IP: 86.246.31.132 Received: from u256.net (lfbn-idf2-1-566-132.w86-246.abo.wanadoo.fr [86.246.31.132]) (Authenticated sender: grive@u256.net) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 3FEDA1BF212; Wed, 22 Apr 2020 09:38:35 +0000 (UTC) Date: Wed, 22 Apr 2020 11:38:30 +0200 From: =?utf-8?Q?Ga=C3=ABtan?= Rivet To: Sunil Kumar Kori Cc: "stephen@networkplumber.org" , "david.marchand@redhat.com" , Jerin Jacob Kollanukkaran , "dev@dpdk.org" Message-ID: <20200422093820.kinhuqy37sjmzffl@u256.net> References: <20200407092856.554-1-skori@marvell.com> <20200420065554.20138-1-skori@marvell.com> <20200421151817.pfcktwfl72mgiuyk@u256.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [dpdk-dev] [EXT] Re: [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 22/04/20 06:17 +0000, Sunil Kumar Kori wrote: > >-----Original Message----- > >From: Gaëtan Rivet > >Sent: Tuesday, April 21, 2020 8:48 PM > >To: Sunil Kumar Kori > >Cc: stephen@networkplumber.org; david.marchand@redhat.com; Jerin Jacob > >Kollanukkaran ; dev@dpdk.org > >Subject: [EXT] Re: [dpdk-dev] [PATCH v3 1/1] bus/pci: optimise scanning with > >whitelist/blacklist > > > >External Email > > > >---------------------------------------------------------------------- > >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. > > > I am also not sure about this. I would request you provide suggestion to ensure that there won't be > any negative consequences if any. So that I can handle those too. > I would like also to hear from other stakeholders for the PCI bus. Generally, as long as the blacklist mode is the default, behavior should not change, but devil is in the details. I would have some comments on the patch itself if everyone agrees with this direction. If the principle of the patch is accepted, it would be great for you to test hotplug and device listing with testpmd: hotplug: * You can spawn VMs with virtual e1000 ports on PCI using QEMU for this, and within testpmd `port attach ` -- of course, the port(s) should not be attached when starting testpmd. You might have to either blacklist them, or you could hotplug them in QEMU using the monitor. I don't recall the QEMU commands to do that, sorry. device list: * `show device info all` in testpmd. I thought I had added a command to test the device iterator, taking an arbitrary device string, but the patch has been dropped it seems. If you have no segfault and no surprise, it is a good start. > >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, > > Recently we observed this requirement to cater a use of having lowest bootup time for DPDK application. > One of the use-case for this to reduce the downtime as part of DPDK SW upgrade in the field. i.e > after the SW update, time to close the application and restart it again for packet processing. > Having this solution application will be up soon and lesser traffic impact will be there in a deployed system. DPDK startup was not written with low latency in mind. You will find here and there minute improvements, but I think it is a pipedream to reduce service disruption on binary upgrade. People in the field would be better served with HA, not relying on a critical apps restarting as fast as possible. Cheers, -- Gaëtan