Re: [dpdk-dev] [EXT] Re: [PATCH v3 1/1] bus/pci: optimise scanning with whitelist/blacklist

[Sunil Kumar Kori <skori@marvell.com>]

>-----Original Message-----
>From: Gaëtan Rivet <grive@u256.net>
>Sent: Tuesday, April 21, 2020 8:48 PM
>To: Sunil Kumar Kori <skori@marvell.com>
>Cc: stephen@networkplumber.org; david.marchand@redhat.com; Jerin Jacob
>Kollanukkaran <jerinj@marvell.com>; 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.

>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.

>--
>Gaëtan