From: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
To: "Tan, Jianfeng" <jianfeng.tan@intel.com>
Cc: dev@dpdk.org, santosh.shukla@caviumnetworks.com,
jerin.jacob@caviumnetworks.com, anatoly.burakov@intel.com
Subject: Re: [PATCH] pci: fix check uio bind
Date: Fri, 20 Oct 2017 22:08:22 +0200 [thread overview]
Message-ID: <20171020200822.GJ3596@bidouze.vm.6wind.com> (raw)
In-Reply-To: <38a126ec-7a6a-b43f-88b1-67e3b6477369@intel.com>
On Sat, Oct 21, 2017 at 12:47:14AM +0800, Tan, Jianfeng wrote:
> Hi Gaëtan,
>
>
> On 10/19/2017 7:42 PM, Gaëtan Rivet wrote:
> >Hi Jianfeng,
> >
> >On Thu, Oct 19, 2017 at 11:18:29AM +0000, Jianfeng Tan wrote:
> >>When checking if any devices bound to uio, we did not exclud
> >>those which are blacklisted (or in the case that a whitelist
> >>is specified).
> >>
> >>This patch fixes it by only checking whitelisted devices.
> >>
> >>Fixes: 815c7deaed2d ("pci: get IOMMU class on Linux")
> >>
> >>Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
> >>---
> >> lib/librte_eal/linuxapp/eal/eal_pci.c | 18 ++++++++++++++++++
> >> 1 file changed, 18 insertions(+)
> >>
> >>diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c b/lib/librte_eal/linuxapp/eal/eal_pci.c
> >>index b4dbf95..2b23d67 100644
> >>--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
> >>+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
> >>@@ -516,8 +516,26 @@ static inline int
> >> pci_one_device_bound_uio(void)
> >> {
> >> struct rte_pci_device *dev = NULL;
> >>+ struct rte_devargs *devargs;
> >>+ int check_all = 1;
> >>+ int need_check;
> >>+
> >>+ if (rte_pci_bus.bus.conf.scan_mode == RTE_BUS_SCAN_WHITELIST)
> >>+ check_all = 0;
> >> FOREACH_DEVICE_ON_PCIBUS(dev) {
> >>+ devargs = dev->device.devargs;
> >>+
> >>+ need_check = 0;
> >>+ if (check_all)
> >Unless I'm mistaken, you will check blacklisted devices as well here.
>
> Thank you for pointing out this.
>
> I was referring to rte_pci_probe(), which also only check "probe_all" and
> (devargs && RTE_DEV_WHITELISTED); but turns out it double checks the
> blacklisted devices in rte_pci_probe_one_driver().
>
> I'll fix it.
>
> >The condition should be something like:
> >
> >if (check_all && devargs == NULL)
>
> >Which means that both ifs can be refactored as
> >
> >if ((check_all ^ (devargs != NULL)) == 0)
> > continue;
> >
> >Removing need_check. But it can be hard to read.
>
> Yes, I prefer to make it easy to understand. Please let me know if you are
> OK with below code (remove check_all):
>
> FOREACH_DEVICE_ON_PCIBUS(dev) {
> devargs = dev->device.devargs;
>
> need_check = 0;
> switch (rte_pci_bus.bus.conf.scan_mode) {
> case RTE_BUS_SCAN_UNDEFINED:
> need_check = 1;
> break;
> case RTE_BUS_SCAN_WHITELIST:
> if (devargs && devargs->policy ==
> RTE_DEV_WHITELISTED)
> need_check = 1;
> break;
> case RTE_BUS_SCAN_BLACKLIST:
> if (!devargs || devargs->policy !=
> RTE_DEV_BLACKLISTED)
> need_check = 1;
> break;
> }
>
> if (!need_check)
> continue;
> ...
I like the switch, two remarks however:
1. The SCAN_UNDEFINED basically means blacklist mode for the PCI bus.
This is the reason probe_all was set by testing for WHITELIST
mode: either of the other too would thus trigger the blacklist
behavior.
Thus, I think you could write a fallthrough case for UNDEFINED, that
would go into the BLACKLIST mode.
2. For pointers in general I would test against NULL instead of using
the unary '!'.
I think it is the general policy in DPDK to always explicitly check
against the constant value, but I personally think that for booleans
like need_check the "not" operator is ok.
So I will only highlight the !devargs :)
>
> Thanks,
> Jianfeng
--
Gaëtan Rivet
6WIND
next prev parent reply other threads:[~2017-10-20 20:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-19 11:18 [PATCH] pci: fix check uio bind Jianfeng Tan
2017-10-19 11:42 ` Gaëtan Rivet
2017-10-20 16:47 ` Tan, Jianfeng
2017-10-20 20:08 ` Gaëtan Rivet [this message]
2017-10-23 3:20 ` Tan, Jianfeng
2017-10-24 7:44 ` [PATCH v2] " Jianfeng Tan
2017-10-24 8:25 ` Gaëtan Rivet
2017-10-26 21:48 ` Thomas Monjalon
2017-10-24 8:31 ` santosh
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=20171020200822.GJ3596@bidouze.vm.6wind.com \
--to=gaetan.rivet@6wind.com \
--cc=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=jerin.jacob@caviumnetworks.com \
--cc=jianfeng.tan@intel.com \
--cc=santosh.shukla@caviumnetworks.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.