DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Gaëtan Rivet" <grive@u256.net>
To: Sunil Kumar Kori <skori@marvell.com>
Cc: "stephen@networkplumber.org" <stephen@networkplumber.org>,
	"david.marchand@redhat.com" <david.marchand@redhat.com>,
	Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v3 1/1] bus/pci: optimise scanning with whitelist/blacklist
Date: Wed, 22 Apr 2020 11:38:30 +0200	[thread overview]
Message-ID: <20200422093820.kinhuqy37sjmzffl@u256.net> (raw)
In-Reply-To: <BY5PR18MB310570850BEBD183D29569ABB4D20@BY5PR18MB3105.namprd18.prod.outlook.com>

On 22/04/20 06:17 +0000, Sunil Kumar Kori wrote:
> >-----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.
> 

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 <pci-id>` -- 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

  reply	other threads:[~2020-04-22  9:38 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-16  7:55 [dpdk-dev] [PATCH] bus/pci: restricted bus scanning to allowed devices Sunil Kumar Kori
2019-12-16 16:13 ` Stephen Hemminger
2019-12-17 11:00   ` [dpdk-dev] [EXT] " Sunil Kumar Kori
2020-01-21  8:39     ` Sunil Kumar Kori
     [not found]       ` <MN2PR18MB327936807460D9F2AE4894F3B40F0@MN2PR18MB3279.namprd18.prod.outlook.com>
2020-02-27  8:30         ` Sunil Kumar Kori
2020-03-09  6:06           ` Sunil Kumar Kori
2020-04-06  9:32             ` Sunil Kumar Kori
2020-04-06 13:21               ` David Marchand
2020-04-07  9:21                 ` Sunil Kumar Kori
2020-04-07  9:28 ` [dpdk-dev] [PATCH v2 1/1] bus/pci: optimise scanning with whitelist/blacklist Sunil Kumar Kori
2020-04-17  8:30   ` Sunil Kumar Kori
2020-04-17  8:44   ` David Marchand
2020-04-17 11:15     ` [dpdk-dev] [EXT] " Sunil Kumar Kori
2020-04-17 13:25       ` David Marchand
2020-04-17 15:12         ` Sunil Kumar Kori
2020-04-17 15:35           ` David Marchand
2020-04-17 16:00             ` Sunil Kumar Kori
2020-04-20  6:59               ` Sunil Kumar Kori
2020-04-20  6:55   ` [dpdk-dev] [PATCH v3 " Sunil Kumar Kori
2020-04-21 15:18     ` Gaëtan Rivet
2020-04-22  6:17       ` [dpdk-dev] [EXT] " Sunil Kumar Kori
2020-04-22  9:38         ` Gaëtan Rivet [this message]
2020-04-23  7:47           ` Sunil Kumar Kori
2020-04-27 18:43     ` [dpdk-dev] " Gaëtan Rivet
2020-04-28 13:52       ` [dpdk-dev] [EXT] " Sunil Kumar Kori
2020-05-01 11:39     ` [dpdk-dev] [PATCH v4 " Sunil Kumar Kori
2020-05-01 12:40       ` Sunil Kumar Kori
2020-05-01 21:00       ` Gaëtan Rivet
2020-05-02  7:20         ` [dpdk-dev] [EXT] " Sunil Kumar Kori
2020-05-02  7:42       ` [dpdk-dev] [PATCH v5 " Sunil Kumar Kori
2020-05-02 11:27         ` Gaëtan Rivet
2020-05-04 14:17         ` David Marchand
2020-05-05  5:57           ` [dpdk-dev] [EXT] " Sunil Kumar Kori
2020-05-06 12:54           ` [dpdk-dev] " David Marchand
2020-05-11 14:59         ` David Marchand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200422093820.kinhuqy37sjmzffl@u256.net \
    --to=grive@u256.net \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=jerinj@marvell.com \
    --cc=skori@marvell.com \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).