From: Bruce Richardson <bruce.richardson@intel.com>
To: David Marchand <david.marchand@redhat.com>
Cc: <dev@dpdk.org>, Parav Pandit <parav@nvidia.com>,
Xueming Li <xuemingl@nvidia.com>,
Nipun Gupta <nipun.gupta@amd.com>,
Nikhil Agarwal <nikhil.agarwal@amd.com>,
Hemant Agrawal <hemant.agrawal@nxp.com>,
"Sachin Saxena" <sachin.saxena@nxp.com>,
Chenbo Xia <chenbox@nvidia.com>,
"Tomasz Duszynski" <tduszynski@marvell.com>,
Chengwen Feng <fengchengwen@huawei.com>,
Long Li <longli@microsoft.com>, Wei Hu <weh@microsoft.com>,
Kevin Laatz <kevin.laatz@intel.com>
Subject: Re: [RFC v2 4/5] bus: factorize device selection
Date: Fri, 27 Feb 2026 14:33:56 +0000 [thread overview]
Message-ID: <aaGrVKFm0FFGTKUC@bricha3-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <CAJFAV8ymk6hScCT8x+sPC7o=3AdFxCXN7BywjvkPiprs_BjM2Q@mail.gmail.com>
On Fri, Feb 27, 2026 at 03:17:27PM +0100, David Marchand wrote:
> On Thu, 26 Feb 2026 at 17:32, Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> > > +RTE_EXPORT_INTERNAL_SYMBOL(rte_bus_is_ignored_device)
> > > +bool
> > > +rte_bus_is_ignored_device(const struct rte_bus *bus, const struct rte_devargs *devargs)
> > > +{
> > > + switch (bus->conf.scan_mode) {
> > > + case RTE_BUS_SCAN_ALLOWLIST:
> > > + if (devargs && devargs->policy == RTE_DEV_ALLOWED)
> > > + return false;
> > > + break;
> > > + case RTE_BUS_SCAN_UNDEFINED:
> > > + case RTE_BUS_SCAN_BLOCKLIST:
> > > + if (devargs == NULL || devargs->policy != RTE_DEV_BLOCKED)
> > > + return false;
> > > + break;
> > > + }
> > > + return true;
> > > +}
> >
> > I think this could do with more comments. Am I right in thinking that
> > devargs is NULL on input if the device in question is not referenced by any
> > devargs passed to the app? This seems a little obscure form of input
> > parameter, so I definitely think it needs documenting.
>
> Yes the handling of a NULL devargs is implicit, I can add a comment.
>
>
> > Is there any way the search for the device name that returns the devargs
> > null/non-null pointer can be similarly generalized?
>
> I also wondered about that and it would be better, but I stopped
> quickly when I looked at the bus specific devargs_lookup functions,
> preparing the v2.
>
> For example with the pci bus, names for pci devices can take various
> forms, so the pci bus uses its device specific representation for
> identifying the devargs.
> rte_pci_device_name(&dev->addr,
> dev->name, sizeof(dev->name));
> devargs = pci_devargs_lookup(&dev->addr);
>
> And:
> RTE_EAL_DEVARGS_FOREACH("pci", devargs) {
> devargs->bus->parse(devargs->name, &addr);
> if (!rte_pci_addr_cmp(pci_addr, &addr))
> return devargs;
> }
>
> I suspect vmbus is the same, with this uuid stuff.
>
> And others bus need investigation too.
> I could try to normalize the devargs names for this lookup.. ?
>
That's a nice to have, IMHO. I think if the NULL/non-NULL is properly
commented it's good enough for this set. You can probably note the cleanup
as a TODO in the code as a further reminder.
/Bruce
next prev parent reply other threads:[~2026-02-27 14:34 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-25 11:29 [RFC 1/2] devtools: check packet forwarding in null test David Marchand
2026-02-25 11:29 ` [RFC 2/2] eal: configure initial device probing David Marchand
2026-02-25 12:09 ` Bruce Richardson
2026-02-25 17:53 ` David Marchand
2026-02-26 16:20 ` [RFC v2 0/5] Rework " David Marchand
2026-02-26 16:20 ` [RFC v2 1/5] devtools: check packet forwarding in null test David Marchand
2026-02-26 16:35 ` Bruce Richardson
2026-02-26 16:20 ` [RFC v2 2/5] bus/fslmc: fix bus cleanup David Marchand
2026-02-26 16:20 ` [RFC v2 3/5] drivers/bus: require probe function for NXP drivers David Marchand
2026-02-26 16:24 ` Bruce Richardson
2026-02-26 16:20 ` [RFC v2 4/5] bus: factorize device selection David Marchand
2026-02-26 16:31 ` Bruce Richardson
2026-02-27 14:17 ` David Marchand
2026-02-27 14:33 ` Bruce Richardson [this message]
2026-02-26 16:20 ` [RFC v2 5/5] eal: configure initial device probing David Marchand
2026-02-26 16:34 ` Bruce Richardson
2026-02-26 16:50 ` Robin Jarry
2026-02-27 13:43 ` Thomas Monjalon
2026-02-27 13:51 ` Bruce Richardson
2026-02-27 22:10 ` Stephen Hemminger
2026-03-02 9:02 ` Bruce Richardson
2026-03-02 11:08 ` Morten Brørup
2026-03-02 11:13 ` David Marchand
2026-03-05 16:45 ` [RFC v3 0/7] Rework " David Marchand
2026-03-05 16:45 ` [RFC v3 1/7] devtools: check packet forwarding in null test David Marchand
2026-03-05 16:45 ` [RFC v3 2/7] bus/fslmc: fix bus cleanup David Marchand
2026-03-05 16:45 ` [RFC v3 3/7] drivers/bus: require probe function for NXP drivers David Marchand
2026-03-05 16:45 ` [RFC v3 4/7] drivers: cleanup devargs lookup in bus scan David Marchand
2026-03-05 16:56 ` Bruce Richardson
2026-03-05 16:45 ` [RFC v3 5/7] bus: factorize devargs lookup David Marchand
2026-03-05 17:06 ` Bruce Richardson
2026-03-05 17:10 ` David Marchand
2026-03-05 16:45 ` [RFC v3 6/7] bus: factorize device selection David Marchand
2026-03-05 17:30 ` Bruce Richardson
2026-03-09 9:50 ` David Marchand
2026-03-07 20:59 ` Robin Jarry
2026-03-05 16:45 ` [RFC v3 7/7] eal: configure initial device probing David Marchand
2026-03-05 17:33 ` Bruce Richardson
2026-03-07 21:05 ` Robin Jarry
2026-03-06 8:26 ` [RFC v3 0/7] Rework " 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=aaGrVKFm0FFGTKUC@bricha3-mobl1.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=chenbox@nvidia.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=hemant.agrawal@nxp.com \
--cc=kevin.laatz@intel.com \
--cc=longli@microsoft.com \
--cc=nikhil.agarwal@amd.com \
--cc=nipun.gupta@amd.com \
--cc=parav@nvidia.com \
--cc=sachin.saxena@nxp.com \
--cc=tduszynski@marvell.com \
--cc=weh@microsoft.com \
--cc=xuemingl@nvidia.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