All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: Andrew Rybchenko <arybchenko@solarflare.com>, dev@dpdk.org
Subject: Re: [PATCH v2 2/4] ethdev: add siblings iterators
Date: Tue, 19 Mar 2019 18:34:21 +0100	[thread overview]
Message-ID: <59747746.vl7xl9E5pD@xps> (raw)
In-Reply-To: <0f5b0dc3-05c6-0f64-1643-7fc23aebfc0a@intel.com>

19/03/2019 16:47, Ferruh Yigit:
> 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.

Yes we need them both in .h and .c files.

> > +rte_eth_find_next_of(uint16_t port_id, const struct rte_device *parent)
> 
> Out of curiosity, what '_of' refers to?

It means "next port of parent".
Is there a better word than "of"?

> > +{
> > +	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.

Oops, I think you are right.

> +1 to Gaetan's suggestion to use 'rte_eth_find_next()', which moves status
> concern to that function.

OK, will change.

> > +
> > +	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

OK

> > +{
> > +	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?

I'm not a fan of extra checks, but yes we may add one.

> > --- a/lib/librte_ethdev/rte_ethdev.h
> > +++ b/lib/librte_ethdev/rte_ethdev.h
> > +/**
> > + * 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?

Yes, OK.

> > + */
> > +__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.

Right, looks like a wrong a copy/paste.

> > + * 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.

Absolutely, yes. I thought I did it.

> > +#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))

Thanks for the complete review Ferruh.

  reply	other threads:[~2019-03-19 17:34 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-30  0:27 [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 ` [PATCH v2 0/4] ethdev iterators for multi-ports device Thomas Monjalon
2019-02-20 22:10   ` [PATCH v2 1/4] ethdev: simplify port state comparisons Thomas Monjalon
2019-02-24 17:18     ` Andrew Rybchenko
2019-02-20 22:10   ` [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-03-19 15:47     ` Ferruh Yigit
2019-03-19 17:34       ` Thomas Monjalon [this message]
2019-03-19 18:04         ` Ferruh Yigit
2019-04-01  2:16           ` Thomas Monjalon
2019-04-01  6:46             ` David Marchand
2019-04-01  8:09               ` Thomas Monjalon
2019-04-02 23:35                 ` Ferruh Yigit
2019-04-02 23:37                   ` Thomas Monjalon
2019-02-20 22:10   ` [PATCH v2 3/4] net/mlx5: use port sibling iterators Thomas Monjalon
2019-02-20 22:10   ` [PATCH v2 4/4] app/testpmd: use port sibling iterator in device cleanup Thomas Monjalon
2019-04-01  2:26 ` [PATCH v3 0/4] ethdev iterators for multi-ports device Thomas Monjalon
2019-04-01  2:26   ` [PATCH v3 1/4] ethdev: simplify port state comparisons Thomas Monjalon
2019-04-01 14:58     ` Stephen Hemminger
2019-04-01 15:17       ` Thomas Monjalon
2019-04-01 16:07         ` Stephen Hemminger
2019-04-03 15:03     ` Slava Ovsiienko
2019-04-01  2:26   ` [PATCH v3 2/4] ethdev: add siblings iterators Thomas Monjalon
2019-04-01  7:23     ` Andrew Rybchenko
2019-04-02 23:42     ` Ferruh Yigit
2019-04-02 23:48       ` Thomas Monjalon
2019-04-03 15:03     ` Slava Ovsiienko
2019-04-01  2:26   ` [PATCH v3 3/4] net/mlx5: use port sibling iterators Thomas Monjalon
2019-04-03 14:19     ` Ferruh Yigit
2019-04-03 18:07       ` Yongseok Koh
2019-04-04 11:33         ` Ferruh Yigit
2019-04-03 15:04     ` Slava Ovsiienko
2019-04-01  2:27   ` [PATCH v3 4/4] app/testpmd: use port sibling iterator in device cleanup Thomas Monjalon
2019-04-02 23:43     ` Ferruh Yigit
2019-04-03 15:04     ` Slava Ovsiienko
2019-04-03 16:42   ` [PATCH v3 0/4] ethdev iterators for multi-ports device 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=59747746.vl7xl9E5pD@xps \
    --to=thomas@monjalon.net \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.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.