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: Thu, 26 Feb 2026 16:31:51 +0000	[thread overview]
Message-ID: <aaB1dz2s2adE8ZCO@bricha3-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <20260226162057.207202-5-david.marchand@redhat.com>

On Thu, Feb 26, 2026 at 05:20:55PM +0100, David Marchand wrote:
> All buses (thankfully) implement the same logic when it comes to
> selecting the devices to probe based on -a/-b options.
> As we want to adjust how devices are selected, provide a common helper
> in EAL and use it in the buses.
> 
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
>  drivers/bus/auxiliary/auxiliary_common.c | 15 +----------
>  drivers/bus/cdx/cdx.c                    | 21 +---------------
>  drivers/bus/dpaa/dpaa_bus.c              | 24 ++++++------------
>  drivers/bus/fslmc/fslmc_bus.c            | 22 ++++++----------
>  drivers/bus/pci/pci_common.c             | 15 +----------
>  drivers/bus/platform/platform.c          | 28 ++-------------------
>  drivers/bus/uacce/uacce.c                | 22 +---------------
>  drivers/bus/vmbus/vmbus_common.c         | 21 +---------------
>  drivers/dma/idxd/idxd_bus.c              | 32 +++++++++---------------
>  lib/eal/common/eal_common_bus.c          | 18 +++++++++++++
>  lib/eal/include/bus_driver.h             |  7 ++++++
>  11 files changed, 58 insertions(+), 167 deletions(-)
> 

<snip>

> diff --git a/lib/eal/common/eal_common_bus.c b/lib/eal/common/eal_common_bus.c
> index 0a2311a342..fbe20cfe35 100644
> --- a/lib/eal/common/eal_common_bus.c
> +++ b/lib/eal/common/eal_common_bus.c
> @@ -8,6 +8,7 @@
>  
>  #include <bus_driver.h>
>  #include <rte_debug.h>
> +#include <rte_devargs.h>
>  #include <rte_string_fns.h>
>  #include <rte_errno.h>
>  
> @@ -226,6 +227,23 @@ rte_bus_find_by_device_name(const char *str)
>  	return rte_bus_find(NULL, bus_can_parse, name);
>  }
>  
> +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.

Is there any way the search for the device name that returns the devargs
null/non-null pointer can be similarly generalized?

>  
>  /*
>   * Get iommu class of devices on the bus.
> diff --git a/lib/eal/include/bus_driver.h b/lib/eal/include/bus_driver.h
> index 60527b75b6..1ec1ff57bb 100644
> --- a/lib/eal/include/bus_driver.h
> +++ b/lib/eal/include/bus_driver.h
> @@ -302,6 +302,13 @@ RTE_INIT_PRIO(businitfn_ ##nm, BUS) \
>  __rte_internal
>  void rte_bus_unregister(struct rte_bus *bus);
>  
> +/**
> + * Indicate if a device referenced by some devargs should be skipped during
> + * probing of a bus.
> + */
> +__rte_internal
> +bool rte_bus_is_ignored_device(const struct rte_bus *bus, const struct rte_devargs *devargs);
> +
>  #ifdef __cplusplus
>  }
>  #endif
> -- 
> 2.53.0
> 

  reply	other threads:[~2026-02-26 16:32 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 [this message]
2026-02-27 14:17       ` David Marchand
2026-02-27 14:33         ` Bruce Richardson
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=aaB1dz2s2adE8ZCO@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