public inbox for dev@dpdk.org
 help / color / mirror / Atom feed
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

  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