From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>,
Shahaf Shuler <shahafs@mellanox.com>,
Yongseok Koh <yskoh@mellanox.com>,
Andrew Rybchenko <arybchenko@solarflare.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: avoid explicit check of valid port state
Date: Thu, 18 Apr 2019 12:50:50 +0100 [thread overview]
Message-ID: <a148b99b-e509-9be3-8358-77d780e52f8e@intel.com> (raw)
Message-ID: <20190418115050.MsEpawukZw5MUJSBOiXX4Gv6bTwiKEUOWKk5WHDX7Lw@z> (raw)
In-Reply-To: <20190417225928.8962-1-thomas@monjalon.net>
On 4/17/2019 11:59 PM, Thomas Monjalon wrote:
> Some port iterations are manually checking against RTE_ETH_DEV_UNUSED
> instead of using the iterators based on rte_eth_find_next().
>
> A new macro RTE_ETH_FOREACH_VALID_DEV() is introduced, but kept private
> because there should be no need of iterating over all devices in the API.
> The public iterators have additional filters for ownership, parent device
> or sibling ports.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> drivers/net/mlx5/mlx5.c | 9 ++-------
> lib/librte_ethdev/rte_ethdev.c | 25 ++++++++++++-------------
No strong opinion but should we separate patch for driver and the library,
logically both changes RTE_ETH_DEV_UNUSED check with macros, but there is no
dependency, I mean they are individual changes, driver patch will be valid on
its own.
> 2 files changed, 14 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
> index 9ff50dfbe..4deaada5c 100644
> --- a/drivers/net/mlx5/mlx5.c
> +++ b/drivers/net/mlx5/mlx5.c
> @@ -1964,14 +1964,9 @@ static int
> mlx5_pci_remove(struct rte_pci_device *pci_dev)
> {
> uint16_t port_id;
> - struct rte_eth_dev *port;
>
> - for (port_id = 0; port_id < RTE_MAX_ETHPORTS; port_id++) {
> - port = &rte_eth_devices[port_id];
> - if (port->state != RTE_ETH_DEV_UNUSED &&
> - port->device == &pci_dev->device)
> - rte_eth_dev_close(port_id);
> - }
> + RTE_ETH_FOREACH_DEV_OF(port_id, &pci_dev->device)
> + rte_eth_dev_close(port_id);
> return 0;
> }
>
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> index 243beb4dd..cca15efca 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -339,6 +339,11 @@ rte_eth_find_next(uint16_t port_id)
> return port_id;
> }
>
> +#define RTE_ETH_FOREACH_VALID_DEV(port_id) \
> + for (port_id = rte_eth_find_next(0); \
> + port_id < RTE_MAX_ETHPORTS; \
> + port_id = rte_eth_find_next(port_id + 1))
> +
What do you think adding some documentation to the new macro, specially I think
documenting the difference between "RTE_ETH_FOREACH_DEV" and this one can be
good otherwise it may confuse people that "RTE_ETH_FOREACH_DEV" iterates on
invalid devices too?
> uint16_t
> rte_eth_find_next_of(uint16_t port_id, const struct rte_device *parent)
> {
> @@ -584,13 +589,10 @@ rte_eth_is_valid_owner_id(uint64_t owner_id)
> uint64_t
> rte_eth_find_next_owned_by(uint16_t port_id, const uint64_t owner_id)
> {
> + port_id = rte_eth_find_next(port_id);
> while (port_id < RTE_MAX_ETHPORTS &&
> - (rte_eth_devices[port_id].state == RTE_ETH_DEV_UNUSED ||
> - rte_eth_devices[port_id].data->owner.id != owner_id))
> - port_id++;
> -
> - if (port_id >= RTE_MAX_ETHPORTS)
> - return RTE_MAX_ETHPORTS;
> + rte_eth_devices[port_id].data->owner.id != owner_id)
> + port_id = rte_eth_find_next(port_id + 1);
>
> return port_id;
> }
> @@ -768,9 +770,8 @@ rte_eth_dev_count_total(void)
> {
> uint16_t port, count = 0;
>
> - for (port = 0; port < RTE_MAX_ETHPORTS; port++)
> - if (rte_eth_devices[port].state != RTE_ETH_DEV_UNUSED)
> - count++;
> + RTE_ETH_FOREACH_VALID_DEV(port)
> + count++;
>
> return count;
> }
> @@ -804,13 +805,11 @@ rte_eth_dev_get_port_by_name(const char *name, uint16_t *port_id)
> return -EINVAL;
> }
>
> - for (pid = 0; pid < RTE_MAX_ETHPORTS; pid++) {
> - if (rte_eth_devices[pid].state != RTE_ETH_DEV_UNUSED &&
> - !strcmp(name, rte_eth_dev_shared_data->data[pid].name)) {
> + RTE_ETH_FOREACH_VALID_DEV(pid)
> + if (!strcmp(name, rte_eth_dev_shared_data->data[pid].name)) {
> *port_id = pid;
> return 0;
> }
> - }
>
> return -ENODEV;
> }
>
next prev parent reply other threads:[~2019-04-18 11:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-17 22:59 Thomas Monjalon
2019-04-17 22:59 ` Thomas Monjalon
2019-04-17 22:59 ` [dpdk-dev] [PATCH 2/2] ethdev: promote function for port count as stable Thomas Monjalon
2019-04-17 22:59 ` Thomas Monjalon
2019-04-18 11:51 ` Ferruh Yigit
2019-04-18 11:51 ` Ferruh Yigit
2019-04-18 12:34 ` Andrew Rybchenko
2019-04-18 12:34 ` Andrew Rybchenko
2019-04-18 11:50 ` Ferruh Yigit [this message]
2019-04-18 11:50 ` [dpdk-dev] [PATCH 1/2] ethdev: avoid explicit check of valid port state Ferruh Yigit
2019-04-18 12:47 ` Thomas Monjalon
2019-04-18 12:47 ` Thomas Monjalon
2019-04-18 17:38 ` Thomas Monjalon
2019-04-18 17:38 ` Thomas Monjalon
2019-04-18 18:37 ` Ferruh Yigit
2019-04-18 18:37 ` 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=a148b99b-e509-9be3-8358-77d780e52f8e@intel.com \
--to=ferruh.yigit@intel.com \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=shahafs@mellanox.com \
--cc=thomas@monjalon.net \
--cc=yskoh@mellanox.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).