DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>,
	Andrew Rybchenko <arybchenko@solarflare.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2 2/4] ethdev: add siblings iterators
Date: Tue, 19 Mar 2019 15:47:42 +0000	[thread overview]
Message-ID: <0f5b0dc3-05c6-0f64-1643-7fc23aebfc0a@intel.com> (raw)
Message-ID: <20190319154742.e9MhFygcTBLzaub2TdJSvQlsZ2YS5M4hum0T9QTmiGw@z> (raw)
In-Reply-To: <20190220221051.7928-3-thomas@monjalon.net>

On 2/20/2019 10:10 PM, Thomas Monjalon wrote:
> If multiple ports share the same hardware device (rte_device),
> they are siblings and can be found thanks to the new functions
> and loop macros.
> One iterator takes a port id as reference,
> while the other one directly refers to the parent device.
> 
> The ownership is not checked because siblings may have
> different owners.
> 
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
>  lib/librte_ethdev/rte_ethdev.c           | 20 +++++++++++
>  lib/librte_ethdev/rte_ethdev.h           | 46 ++++++++++++++++++++++++
>  lib/librte_ethdev/rte_ethdev_version.map |  2 ++
>  3 files changed, 68 insertions(+)
> 
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> index b3b2fb1dba..42154787f8 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -340,6 +340,26 @@ rte_eth_find_next(uint16_t port_id)
>  	return port_id;
>  }
>  
> +uint16_t __rte_experimental

Do we need _rte_experimental on function definitions? I guess only in .h file,
function declaration is enough.

> +rte_eth_find_next_of(uint16_t port_id, const struct rte_device *parent)

Out of curiosity, what '_of' refers to?

> +{
> +	while (port_id < RTE_MAX_ETHPORTS &&
> +			rte_eth_devices[port_id].state == RTE_ETH_DEV_UNUSED &&
> +			rte_eth_devices[port_id].device != parent)
> +		port_id++;

Is this logic correct, or am I missing something.
When port status is ATTACHED, check will return false and exit from loop without
checking if the 'device' is same.
+1 to Gaetan's suggestion to use 'rte_eth_find_next()', which moves status
concern to that function.

> +
> +	if (port_id >= RTE_MAX_ETHPORTS)
> +		return RTE_MAX_ETHPORTS;
> +
> +	return port_id;
> +}
> +
> +uint16_t __rte_experimental
> +rte_eth_find_next_sibling(uint16_t port_id, uint16_t ref)

I think better to say 'ref_port_id' to clarify what we expect here is a port_id

> +{
> +	return rte_eth_find_next_of(port_id, rte_eth_devices[ref].device);

This is a public API, shouldn't we check if 'ref' if valid port_id value, before
accessing the '.device' field?

> +}
> +
>  static void
>  rte_eth_dev_shared_data_prepare(void)
>  {
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index a3c864a134..a7c5c36277 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -1383,6 +1383,52 @@ uint16_t rte_eth_find_next(uint16_t port_id);
>  #define RTE_ETH_FOREACH_DEV(p) \
>  	RTE_ETH_FOREACH_DEV_OWNED_BY(p, RTE_ETH_DEV_NO_OWNER)
>  
> +/**
> + * Iterates over ethdev ports of a specified device.
> + *
> + * @param port_id_start
> + *   The id of the next possible valid port.
> + * @param parent
> + *   The generic device behind the ports to iterate.
> + * @return
> + *   Next port id of the device, RTE_MAX_ETHPORTS if there is none.

Can return 'port_id_start', right? Should it be documented as it is done in
below 'next_sibling' one?

> + */
> +__rte_experimental
> +uint16_t rte_eth_find_next_of(uint16_t port_id_start,
> +		const struct rte_device *parent);
> +
> +/**
> + * Macro to iterate over all ethdev ports sharing the same rte_device
> + * as the specified port.

'specified port'? No port specified, a device pointer is specified.

> + * Note: the specified port is part of the loop iterations.
> + */

Does it make sense to clarify what 'p' is and what 'parent' is as we do in
function doxygen comments? Since these are macros, harder to grasp the types, I
think better to describe more in macro documentation.

> +#define RTE_ETH_FOREACH_DEV_OF(p, parent) \
> +	for (p = rte_eth_find_next_of(0, parent); \
> +		p < RTE_MAX_ETHPORTS; \
> +		p = rte_eth_find_next_of(p + 1, parent))
> +
> +/**
> + * Iterates over sibling ethdev ports (i.e. sharing the same rte_device).
> + *
> + * @param port_id_start
> + *   The id of the next possible valid sibling port.
> + * @param ref
> + *   The id of a reference port to compare rte_device with.
> + * @return
> + *   Next sibling port id (or ref itself), RTE_MAX_ETHPORTS if there is none.
> + */
> +__rte_experimental
> +uint16_t rte_eth_find_next_sibling(uint16_t port_id_start, uint16_t ref);
> +
> +/**
> + * Macro to iterate over all ethdev ports sharing the same rte_device
> + * as the specified port.
> + * Note: the specified port is part of the loop iterations.
> + */
> +#define RTE_ETH_FOREACH_DEV_SIBLING(p, ref) \
> +	for (p = rte_eth_find_next_sibling(0, ref); \
> +		p < RTE_MAX_ETHPORTS; \
> +		p = rte_eth_find_next_sibling(p + 1, ref))
>  
>  /**
>   * @warning
> diff --git a/lib/librte_ethdev/rte_ethdev_version.map b/lib/librte_ethdev/rte_ethdev_version.map
> index 92ac3de250..b37a4167d7 100644
> --- a/lib/librte_ethdev/rte_ethdev_version.map
> +++ b/lib/librte_ethdev/rte_ethdev_version.map
> @@ -245,6 +245,8 @@ EXPERIMENTAL {
>  	rte_eth_dev_owner_set;
>  	rte_eth_dev_owner_unset;
>  	rte_eth_dev_rx_intr_ctl_q_get_fd;
> +	rte_eth_find_next_of;
> +	rte_eth_find_next_sibling;
>  	rte_eth_switch_domain_alloc;
>  	rte_eth_switch_domain_free;
>  	rte_flow_conv;
> 


  parent reply	other threads:[~2019-03-19 15:47 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-30  0:27 [dpdk-dev] [PATCH] ethdev: add siblings iterator Thomas Monjalon
2018-12-11 16:31 ` Ferruh Yigit
2018-12-11 18:19   ` Thomas Monjalon
2019-02-20 22:10 ` [dpdk-dev] [PATCH v2 0/4] ethdev iterators for multi-ports device Thomas Monjalon
2019-02-20 22:10   ` [dpdk-dev] [PATCH v2 1/4] ethdev: simplify port state comparisons Thomas Monjalon
2019-02-24 17:18     ` Andrew Rybchenko
2019-02-20 22:10   ` [dpdk-dev] [PATCH v2 2/4] ethdev: add siblings iterators Thomas Monjalon
2019-02-24 17:22     ` Andrew Rybchenko
2019-02-27 10:07     ` Gaëtan Rivet
2019-02-27 10:51       ` Thomas Monjalon
2019-04-01  1:59         ` Thomas Monjalon
2019-04-01  1:59           ` Thomas Monjalon
2019-03-19 15:47     ` Ferruh Yigit [this message]
2019-03-19 15:47       ` Ferruh Yigit
2019-03-19 17:34       ` Thomas Monjalon
2019-03-19 17:34         ` Thomas Monjalon
2019-03-19 18:04         ` Ferruh Yigit
2019-03-19 18:04           ` Ferruh Yigit
2019-04-01  2:16           ` Thomas Monjalon
2019-04-01  2:16             ` Thomas Monjalon
2019-04-01  6:46             ` David Marchand
2019-04-01  6:46               ` David Marchand
2019-04-01  8:09               ` Thomas Monjalon
2019-04-01  8:09                 ` Thomas Monjalon
2019-04-02 23:35                 ` Ferruh Yigit
2019-04-02 23:35                   ` Ferruh Yigit
2019-04-02 23:37                   ` Thomas Monjalon
2019-04-02 23:37                     ` Thomas Monjalon
2019-02-20 22:10   ` [dpdk-dev] [PATCH v2 3/4] net/mlx5: use port sibling iterators Thomas Monjalon
2019-02-20 22:10   ` [dpdk-dev] [PATCH v2 4/4] app/testpmd: use port sibling iterator in device cleanup Thomas Monjalon
2019-04-01  2:26 ` [dpdk-dev] [PATCH v3 0/4] ethdev iterators for multi-ports device Thomas Monjalon
2019-04-01  2:26   ` Thomas Monjalon
2019-04-01  2:26   ` [dpdk-dev] [PATCH v3 1/4] ethdev: simplify port state comparisons Thomas Monjalon
2019-04-01  2:26     ` Thomas Monjalon
2019-04-01 14:58     ` Stephen Hemminger
2019-04-01 14:58       ` Stephen Hemminger
2019-04-01 15:17       ` Thomas Monjalon
2019-04-01 15:17         ` Thomas Monjalon
2019-04-01 16:07         ` Stephen Hemminger
2019-04-01 16:07           ` Stephen Hemminger
2019-04-03 15:03     ` Slava Ovsiienko
2019-04-03 15:03       ` Slava Ovsiienko
2019-04-01  2:26   ` [dpdk-dev] [PATCH v3 2/4] ethdev: add siblings iterators Thomas Monjalon
2019-04-01  2:26     ` Thomas Monjalon
2019-04-01  7:23     ` Andrew Rybchenko
2019-04-01  7:23       ` Andrew Rybchenko
2019-04-02 23:42     ` Ferruh Yigit
2019-04-02 23:42       ` Ferruh Yigit
2019-04-02 23:48       ` Thomas Monjalon
2019-04-02 23:48         ` Thomas Monjalon
2019-04-03 15:03     ` Slava Ovsiienko
2019-04-03 15:03       ` Slava Ovsiienko
2019-04-01  2:26   ` [dpdk-dev] [PATCH v3 3/4] net/mlx5: use port sibling iterators Thomas Monjalon
2019-04-01  2:26     ` Thomas Monjalon
2019-04-03 14:19     ` Ferruh Yigit
2019-04-03 14:19       ` Ferruh Yigit
2019-04-03 18:07       ` Yongseok Koh
2019-04-03 18:07         ` Yongseok Koh
2019-04-04 11:33         ` Ferruh Yigit
2019-04-04 11:33           ` Ferruh Yigit
2019-04-03 15:04     ` Slava Ovsiienko
2019-04-03 15:04       ` Slava Ovsiienko
2019-04-01  2:27   ` [dpdk-dev] [PATCH v3 4/4] app/testpmd: use port sibling iterator in device cleanup Thomas Monjalon
2019-04-01  2:27     ` Thomas Monjalon
2019-04-02 23:43     ` Ferruh Yigit
2019-04-02 23:43       ` Ferruh Yigit
2019-04-03 15:04     ` Slava Ovsiienko
2019-04-03 15:04       ` Slava Ovsiienko
2019-04-03 16:42   ` [dpdk-dev] [PATCH v3 0/4] ethdev iterators for multi-ports device Ferruh Yigit
2019-04-03 16:42     ` Ferruh Yigit

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=0f5b0dc3-05c6-0f64-1643-7fc23aebfc0a@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=thomas@monjalon.net \
    /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).