All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nélio Laranjeiro" <nelio.laranjeiro@6wind.com>
To: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Cc: dev@dpdk.org, Yongseok Koh <yskoh@mellanox.com>
Subject: Re: [PATCH 2/2] net/mlx5: fix link status to use wait to complete
Date: Fri, 16 Feb 2018 13:08:00 +0100	[thread overview]
Message-ID: <20180216120800.dggonqh55lrvzhhg@laranjeiro-vm.dev.6wind.com> (raw)
In-Reply-To: <20180216104900.GC4256@6wind.com>

On Fri, Feb 16, 2018 at 11:49:00AM +0100, Adrien Mazarguil wrote:
> On Thu, Feb 15, 2018 at 09:47:28AM +0100, Nelio Laranjeiro wrote:
> > Wait to complete is present to let the application get a correct status
> > when it requires it, it should not be ignored.
> > 
> > Fixes: cb8faed7dde8 ("mlx5: support link status update")
> > Cc: adrien.mazarguil@6wind.com
> > 
> > Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
> 
> Several comments, please see below.
> 
> > ---
> >  drivers/net/mlx5/mlx5_ethdev.c | 35 +++++++++++++++++++++--------------
> >  1 file changed, 21 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
> > index 0ce9f438a..112cc2a40 100644
> > --- a/drivers/net/mlx5/mlx5_ethdev.c
> > +++ b/drivers/net/mlx5/mlx5_ethdev.c
> > @@ -502,11 +502,12 @@ mlx5_dev_supported_ptypes_get(struct rte_eth_dev *dev)
> >   *
> >   * @param dev
> >   *   Pointer to Ethernet device structure.
> > - * @param wait_to_complete
> > - *   Wait for request completion (ignored).
> > + *
> > + * @return
> > + *   0 on success, -1 otherwise.
> 
> See below regarding the return value.
> 
> >   */
> >  static int
> > -mlx5_link_update_unlocked_gset(struct rte_eth_dev *dev, int wait_to_complete)
> > +mlx5_link_update_unlocked_gset(struct rte_eth_dev *dev)
> >  {
> >  	struct priv *priv = dev->data->dev_private;
> >  	struct ethtool_cmd edata = {
> > @@ -518,7 +519,6 @@ mlx5_link_update_unlocked_gset(struct rte_eth_dev *dev, int wait_to_complete)
> >  
> >  	/* priv_lock() is not taken to allow concurrent calls. */
> >  
> > -	(void)wait_to_complete;
> >  	if (priv_ifreq(priv, SIOCGIFFLAGS, &ifr)) {
> >  		WARN("ioctl(SIOCGIFFLAGS) failed: %s", strerror(errno));
> >  		return -1;
> > @@ -568,11 +568,9 @@ mlx5_link_update_unlocked_gset(struct rte_eth_dev *dev, int wait_to_complete)
> >   *
> >   * @param dev
> >   *   Pointer to Ethernet device structure.
> > - * @param wait_to_complete
> > - *   Wait for request completion (ignored).
> 
> You should use this opportunity to document its return value as well.
> 
> >   */
> >  static int
> > -mlx5_link_update_unlocked_gs(struct rte_eth_dev *dev, int wait_to_complete)
> > +mlx5_link_update_unlocked_gs(struct rte_eth_dev *dev)
> >  {
> >  	struct priv *priv = dev->data->dev_private;
> >  	struct ethtool_link_settings gcmd = { .cmd = ETHTOOL_GLINKSETTINGS };
> > @@ -580,7 +578,6 @@ mlx5_link_update_unlocked_gs(struct rte_eth_dev *dev, int wait_to_complete)
> >  	struct rte_eth_link dev_link;
> >  	uint64_t sc;
> >  
> > -	(void)wait_to_complete;
> >  	if (priv_ifreq(priv, SIOCGIFFLAGS, &ifr)) {
> >  		WARN("ioctl(SIOCGIFFLAGS) failed: %s", strerror(errno));
> >  		return -1;
> > @@ -708,6 +705,9 @@ priv_link_stop(struct priv *priv)
> >   *   Pointer to private structure.
> >   * @param wait_to_complete
> >   *   Wait for request completion (ignored).
> > + *
> > + * @return
> > + *   0 on success, negative value otherwise.
> 
> How about "0 on success, negative errno value otherwise" according to
> subsequent comments.
> 
> >   */
> >  int
> >  priv_link_update(struct priv *priv, int wait_to_complete)
> > @@ -720,10 +720,16 @@ priv_link_update(struct priv *priv, int wait_to_complete)
> >  		current_version >= KERNEL_VERSION(4, 9, 0) :
> >  		0;
> >  
> > -	if (use_new_api)
> > -		ret = mlx5_link_update_unlocked_gset(dev, wait_to_complete);
> > -	else
> > -		ret = mlx5_link_update_unlocked_gs(dev, wait_to_complete);
> > +	do {
> > +		if (use_new_api)
> > +			ret = mlx5_link_update_unlocked_gset(dev);
> > +		else
> > +			ret = mlx5_link_update_unlocked_gs(dev);
> > +		if (ret == -1)
> > +			return -EAGAIN;
> 
> Like for system calls, EAGAIN isn't an acceptable error in case
> wait_to_complete (blocking mode) is requested. It must be some other reason.
> 
> This check should be replaced with my next suggestion.
> 
> > +	} while(wait_to_complete && !ret);
> 
> Missing space after "while".
> 
> One issue is when wait_to_complete is enabled and link status never settles
> down due to bad cabling or buggy SFP. I think this function should give up
> and return an error after a while (not -EAGAIN in this case but -EIO, -EBUSY
> or even -EINTR to reflect the call had to be interrupted due to HW trouble).
> 
> You could use MLX5_MAX_LINK_QUERY_ATTEMPTS for that, e.g.:
> 
>  int attempt = MLX5_MAX_LINK_QUERY_ATTEMPTS;
>  [...]
>  while (1) {
>     [...]
>     if (!wait_to_complete || ret != -EAGAIN || !attempt--)
>         break;
>     sleep(1);  
>  }
> 
> > +	if (ret == -EAGAIN)
> > +		return ret;
> 
> Since neither function may return anything other than -1 in case of error at
> the moment and since their wait_to_complete argument is being removed, I
> suggest to make them properly non-blocking by default (i.e. O_NONBLOCK on
> their ioctl() FD), then return -errno in case of error on intermediate
> system calls, then the above check will make sense.
> 
> >  	/* If lsc interrupt is disabled, should always be ready for traffic. */
> >  	if (!dev->data->dev_conf.intr_conf.lsc) {
> >  		priv_link_start(priv);
> > @@ -755,10 +761,11 @@ int
> >  priv_force_link_status_change(struct priv *priv, int status)
> >  {
> >  	int try = 0;
> > +	int ret = 0;
> >  
> >  	while (try < MLX5_MAX_LINK_QUERY_ATTEMPTS) {
> > -		priv_link_update(priv, 0);
> > -		if (priv->dev->data->dev_link.link_status == status)
> > +		ret = priv_link_update(priv, 0);
> > +		if (!ret && priv->dev->data->dev_link.link_status == status)
> >  			return 0;
> >  		try++;
> >  		sleep(1);
> 
> I think this function could be removed in the same patch (with e313ef4c2fe8
> "net/mlx5: fix link state on device start" partially reverted) since a call
> to priv_link_update(priv, 1) would now result in the same behavior.
 
Agreed, I'll re-work it in a v2.

Thanks,

-- 
Nélio Laranjeiro
6WIND

  reply	other threads:[~2018-02-16 12:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-15  8:47 [PATCH 1/2] net/mlx5: add kernel version function Nelio Laranjeiro
2018-02-15  8:47 ` [PATCH 2/2] net/mlx5: fix link status to use wait to complete Nelio Laranjeiro
2018-02-16 10:49   ` Adrien Mazarguil
2018-02-16 12:08     ` Nélio Laranjeiro [this message]
2018-02-16 10:48 ` [PATCH 1/2] net/mlx5: add kernel version function Adrien Mazarguil
2018-02-16 18:03 ` Stephen Hemminger
2018-02-19  7:42   ` Nélio Laranjeiro
2018-03-12 13:43 ` [PATCH v2 0/3] net/mlx5: cleanup link status Nelio Laranjeiro
2018-03-19 19:15   ` Shahaf Shuler
2018-03-12 13:43 ` [PATCH v2 1/3] net/mlx5: remove kernel version check Nelio Laranjeiro
2018-03-12 13:43 ` [PATCH v2 2/3] net/mlx5: fix link status behavior Nelio Laranjeiro
2018-03-13 21:54   ` Yongseok Koh
2018-03-14 12:18     ` Adrien Mazarguil
2018-03-14 17:40       ` Yongseok Koh
2018-03-14 19:00         ` Adrien Mazarguil
2018-03-14 12:22     ` Nélio Laranjeiro
2018-03-15 18:08   ` Yongseok Koh
2018-03-12 13:43 ` [PATCH v2 3/3] net/mlx5: fix link status to use wait to complete Nelio Laranjeiro

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=20180216120800.dggonqh55lrvzhhg@laranjeiro-vm.dev.6wind.com \
    --to=nelio.laranjeiro@6wind.com \
    --cc=adrien.mazarguil@6wind.com \
    --cc=dev@dpdk.org \
    --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 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.