From: Thomas Monjalon <thomas@monjalon.net>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: Andrew Rybchenko <arybchenko@solarflare.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] [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)
Message-ID: <20190319173421.YMXfottT2q_TEqQ9-O13j3bZAwVEzhBqFfQn2-5h6ZQ@z> (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.
next prev parent reply other threads:[~2019-03-19 17:34 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
2019-03-19 15:47 ` Ferruh Yigit
2019-03-19 17:34 ` Thomas Monjalon [this message]
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=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 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).