From: Stephen Hemminger <stephen@networkplumber.org>
To: Nitin Katiyar <nitin.katiyar@ericsson.com>
Cc: <dev@dpdk.org>, Venkatesan Pradeep <venkatesan.pradeep@ericsson.com>
Subject: Re: [dpdk-dev] [PATCH 1/2] bus/pci: Fail rte_pci_probe if probing all whitelisted devices fail.
Date: Tue, 27 Aug 2019 16:12:31 -0400 [thread overview]
Message-ID: <20190827161231.6c2313c7@xps13> (raw)
In-Reply-To: <1566934217-23824-1-git-send-email-nitin.katiyar@ericsson.com>
On Wed, 28 Aug 2019 01:00:16 +0530
Nitin Katiyar <nitin.katiyar@ericsson.com> wrote:
> Even if whitelist of devices is provided, rte_pci_probe() increments
> the probed counter for all the devices present in the system. If probe
> fails for all the whitelisted devices it still return success because
> failed and probed counts don't match.
>
> This patch increments probed count only when devices are actually
> probed.
>
> Signed-off-by: Nitin Katiyar <nitin.katiyar@ericsson.com>
> Signed-off-by: Venkatesan Pradeep <venkatesan.pradeep@ericsson.com>
There are two differing interpretations of this.
The simple case which is what your patch fixes is where user gives bad
arguments and no devices are present.
But the more complex case is where the devices show up later via hotplug
or other discovery mechanism. For example, on Hyper-V/Azure SRIOV PCI devices
can show up after application is started. Your patch might break the
use case of where an application is started before the VF is available.
More detailed example:
1. VM is started.
2. VF is take offline for maintenance or migration.
3. DPDK application is started with whitelist option (no usable PCI found).
4. VF becomes available after maintenance.
Yes, this a somewhat made up order which is unlikely to happen in
real life. But there is nothing stopping it from happening.
I often recommend to customers using whitelist because the typical appliance
scenario has a management interface, and you don't want the DPDK interacting
with the VF of the management interface.
Therefore, from my point of view, this patch is a NO.
next prev parent reply other threads:[~2019-08-27 20:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-27 19:30 Nitin Katiyar
2019-08-27 19:30 ` [dpdk-dev] [PATCH 2/2] eal: DPDK init doesn't fail even if device probe fails Nitin Katiyar
2019-08-27 13:57 ` Aaron Conole
2019-08-27 20:12 ` Stephen Hemminger [this message]
2019-08-29 3:47 ` [dpdk-dev] [PATCH 1/2] bus/pci: Fail rte_pci_probe if probing all whitelisted devices fail Nitin Katiyar
2019-08-29 15:33 ` Stephen Hemminger
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=20190827161231.6c2313c7@xps13 \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=nitin.katiyar@ericsson.com \
--cc=venkatesan.pradeep@ericsson.com \
/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).