DPDK patches and discussions
 help / color / mirror / Atom feed
From: Matan Azrad <matan@mellanox.com>
To: Thomas Monjalon <thomas@monjalon.net>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "Morten Brørup" <mb@smartsharesystems.com>,
	"Benoit Ganne" <bganne@cisco.com>,
	"Ferruh Yigit" <ferruh.yigit@intel.com>,
	"Andrew Rybchenko" <arybchenko@solarflare.com>
Subject: Re: [dpdk-dev] [PATCH 2/2] ethdev: allow unknown link speed
Date: Sun, 26 Apr 2020 11:44:22 +0000	[thread overview]
Message-ID: <AM0PR0502MB4019908F7A73DB182EF58203D2AE0@AM0PR0502MB4019.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <20200407222637.55289-3-thomas@monjalon.net>

Hi

From: Thomas Monjalon
> When querying the link informations, the link status is a mandatory major
> information.
> Other boolean values are supposed to be accurate:
> 	- duplex mode (half/full)
> 	- negotiation (auto/fixed)
> 
> This API update is making explicit that the link speed information is optional.
> The value ETH_SPEED_NUM_NONE (0) was already part of the API.
> The value ETH_SPEED_NUM_UNKNOWN (infinite) is added to cover two
> different cases:
> 	- speed is not known by the driver
> 	- device is virtual
> 
> Suggested-by: Morten Brørup <mb@smartsharesystems.com>
> Suggested-by: Benoit Ganne <bganne@cisco.com>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
>  lib/librte_ethdev/rte_ethdev.h | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index d1a593ad11..2d51fd3444 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -300,6 +300,7 @@ struct rte_eth_stats {
>  #define ETH_SPEED_NUM_50G      50000 /**<  50 Gbps */
>  #define ETH_SPEED_NUM_56G      56000 /**<  56 Gbps */
>  #define ETH_SPEED_NUM_100G    100000 /**< 100 Gbps */
> +#define ETH_SPEED_NUM_UNKNOWN UINT32_MAX /**< Unknown */
> 
>  /**
>   * A structure used to retrieve link-level information of an Ethernet port.
> @@ -2245,15 +2246,16 @@ int rte_eth_allmulticast_disable(uint16_t
> port_id);  int rte_eth_allmulticast_get(uint16_t port_id);
> 
>  /**
> - * Retrieve the status (ON/OFF), the speed (in Mbps) and the mode (HALF-
> DUPLEX
> - * or FULL-DUPLEX) of the physical link of an Ethernet device. It might need
> - * to wait up to 9 seconds in it.
> + * Retrieve the link status (up/down), the duplex mode (half/full),
> + * the negotiation (auto/fixed), and if available, the speed (Mbps).
> + *
> + * It might need to wait up to 9 seconds.
> + * @see rte_eth_link_get_nowait.
>   *
>   * @param port_id
>   *   The port identifier of the Ethernet device.
>   * @param link
> - *   A pointer to an *rte_eth_link* structure to be filled with
> - *   the status, the speed and the mode of the Ethernet device link.
> + *   Link informations written back.
>   * @return
>   *   - (0) if successful.
>   *   - (-ENOTSUP) if the function is not supported in PMD driver.
> @@ -2262,15 +2264,13 @@ int rte_eth_allmulticast_get(uint16_t port_id);
> int rte_eth_link_get(uint16_t port_id, struct rte_eth_link *link);
> 
>  /**
> - * Retrieve the status (ON/OFF), the speed (in Mbps) and the mode (HALF-
> DUPLEX
> - * or FULL-DUPLEX) of the physical link of an Ethernet device. It is a no-wait
> - * version of rte_eth_link_get().
> + * Retrieve the link status (up/down), the duplex mode (half/full),
> + * the negotiation (auto/fixed), and if available, the speed (Mbps).

The current API doesn’t say that link speed is optional, so no link speed information means error in API.
When making link speed optional, it may break existing app that expects to get error in API when link speed is not available in order to call the API again.
So I think it breaks API.
I agree for the change but think that this is better to integrate it in 20.11 after sending prior deprecation notice.

Matan


>   *
>   * @param port_id
>   *   The port identifier of the Ethernet device.
>   * @param link
> - *   A pointer to an *rte_eth_link* structure to be filled with
> - *   the status, the speed and the mode of the Ethernet device link.
> + *   Link informations written back.
>   * @return
>   *   - (0) if successful.
>   *   - (-ENOTSUP) if the function is not supported in PMD driver.
> --
> 2.26.0


      parent reply	other threads:[~2020-04-26 11:44 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-01  9:33 [dpdk-dev] [RFC] ethdev: use special speed for virtual Ethernet devices Morten Brørup
2020-04-01  9:53 ` Thomas Monjalon
2020-04-01 10:03   ` Benoit Ganne (bganne)
2020-04-01 10:06   ` [dpdk-dev] [RFC] ethdev: use special speed for virtual Ethernetdevices Morten Brørup
2020-04-02 12:54     ` Ivan Dyukov
2020-04-02 13:50       ` Morten Brørup
2020-04-02 15:29         ` Stephen Hemminger
2020-04-02 20:41         ` Ivan Dyukov
2020-04-02 20:58           ` Thomas Monjalon
2020-04-03  8:05             ` Ivan Dyukov
2020-04-03  9:45               ` Morten Brørup
2020-04-03 11:01                 ` Thomas Monjalon
2020-04-07 22:26                 ` [dpdk-dev] [PATCH 0/2] ethdev link speed Thomas Monjalon
2020-04-07 22:26                   ` [dpdk-dev] [PATCH 1/2] ethdev: deduplicate functions to get link infos Thomas Monjalon
2020-04-08  5:21                     ` Asaf Penso
2020-04-08 12:49                       ` Thomas Monjalon
2020-04-13 14:14                     ` Andrew Rybchenko
2020-04-07 22:26                   ` [dpdk-dev] [PATCH 2/2] ethdev: allow unknown link speed Thomas Monjalon
2020-04-08  5:39                     ` Jerin Jacob
2020-04-10 10:53                     ` Morten Brørup
2020-04-13 14:26                     ` Andrew Rybchenko
2020-04-16 13:42                       ` Ferruh Yigit
2020-04-26 11:44                     ` Matan Azrad [this message]

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=AM0PR0502MB4019908F7A73DB182EF58203D2AE0@AM0PR0502MB4019.eurprd05.prod.outlook.com \
    --to=matan@mellanox.com \
    --cc=arybchenko@solarflare.com \
    --cc=bganne@cisco.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=mb@smartsharesystems.com \
    --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).