DPDK patches and discussions
 help / color / mirror / Atom feed
From: Shahaf Shuler <shahafs@mellanox.com>
To: "Nélio Laranjeiro" <nelio.laranjeiro@6wind.com>
Cc: Adrien Mazarguil <adrien.mazarguil@6wind.com>,
	Yongseok Koh <yskoh@mellanox.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] net/mlx5: fix link status initialization
Date: Sun, 8 Apr 2018 13:09:27 +0000	[thread overview]
Message-ID: <DB7PR05MB44260C397468AAF7008F5490C3B80@DB7PR05MB4426.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <20180405065120.jqttkvlhjflpfdbj@laranjeiro-vm.dev.6wind.com>

Thursday, April 5, 2018 9:51 AM, Nélio Laranjeiro:
> Subject: Re: [PATCH] net/mlx5: fix link status initialization
> 
> On Thu, Apr 05, 2018 at 05:35:57AM +0000, Shahaf Shuler wrote:
> > Wednesday, April 4, 2018 3:11 PM, Nélio Laranjeiro:
> > > Subject: Re: [PATCH] net/mlx5: fix link status initialization
> > >
> > > On Wed, Apr 04, 2018 at 09:58:33AM +0000, Shahaf Shuler wrote:
> > > > Wednesday, April 4, 2018 10:30 AM, Nélio Laranjeiro:
> > > > > Subject: Re: [PATCH] net/mlx5: fix link status initialization
> > > > >
> > > > > On Tue, Apr 03, 2018 at 07:48:17AM +0300, Shahaf Shuler wrote:

[..]

> > >
> > > According to your analysis, this is only necessary when the LCS is
> > > configured in the device.  Why not adding this call to
> > > mlx5_dev_interrupt_handler_install() which is responsible to install
> > > the LCS callback.
> >
> > I think it is good practice whether or not LSC is set.
> > The link status should be initialized to the correct value after the probe.
> 
> There is no guarantee the link will be accurate, at probe time the link may be
> up so internal information has a status up with a speed with this patch.
> The application probes a second port, in the mean time the link of the first
> port goes down, the interrupt is still not installed and the internal status
> becomes wrong (still up whereas the port is down).
> 
> Finally at start, the device installs the handler, but the link is still down
> whereas internally it is up, the application will call
> rte_eth_link_get_nowait() which will directly copy the wrong internal status
> to the application.

This is not correct.
Using Verbs, the async_fd on which link status interrupts are reported is created on probe. 
Even if the interrupt handler is not installed, interrupts still trigger on this fd. They will be processed when the interrupt handler will be installed as part of the port start. 
So in fact you have the whole trace on the link status changes waiting to be processed upon port start. 

Please try and see. 

> 
> There is also another situation, when the application stops the port, the
> interrupt is also removed, which means during this time, the internal status
> may be wrong as it won't be updated anymore.
> This comes to the same possible situation as above.

Same comment. 

> 
> > > Another point, the wait to complete flag is useless, if the link is
> > > up, the status and speed will be accurate, if not, it will receive an LSC
> event later.
> >
> > Agree.
> >
> > So how about keeping the code on the current place, just removing the
> > wait_to_complete?
> 
> The current place is not fixing the issue as there is still a possibility to have a
> wrong value.
> 
> Regards,
> 
> --
> Nélio Laranjeiro
> 6WIND

  reply	other threads:[~2018-04-08 13:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-03  4:48 Shahaf Shuler
2018-04-04  7:30 ` Nélio Laranjeiro
2018-04-04  9:58   ` Shahaf Shuler
2018-04-04 12:10     ` Nélio Laranjeiro
2018-04-05  5:35       ` Shahaf Shuler
2018-04-05  6:51         ` Nélio Laranjeiro
2018-04-08 13:09           ` Shahaf Shuler [this message]
2018-04-09  8:27             ` Nélio Laranjeiro
2018-04-09 12:28               ` Shahaf Shuler
2018-04-09 13:26                 ` Nélio Laranjeiro
2018-04-09 14:07                   ` Nélio Laranjeiro
2018-04-10  6:13 ` [dpdk-dev] [PATCH v2] " Shahaf Shuler
2018-04-10  8:17   ` Nélio Laranjeiro
2018-04-11  9:05     ` Shahaf Shuler

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=DB7PR05MB44260C397468AAF7008F5490C3B80@DB7PR05MB4426.eurprd05.prod.outlook.com \
    --to=shahafs@mellanox.com \
    --cc=adrien.mazarguil@6wind.com \
    --cc=dev@dpdk.org \
    --cc=nelio.laranjeiro@6wind.com \
    --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).