DPDK patches and discussions
 help / color / mirror / Atom feed
From: Matan Azrad <matan@mellanox.com>
To: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"stable@dpdk.org" <stable@dpdk.org>,
	"Ophir Munk" <ophirmu@mellanox.com>
Subject: Re: [dpdk-dev] [PATCH v5 2/3] net/failsafe: fix removal scope
Date: Thu, 8 Feb 2018 19:03:15 +0000	[thread overview]
Message-ID: <AM4PR0501MB265749F33C515836EA2A4211D2F30@AM4PR0501MB2657.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <20180208171931.oxiqp6433pmft36m@bidouze.vm.6wind.com>

Hi Gaetan

From: Gaëtan Rivet, Thursday, February 8, 2018 7:20 PM
> Hi Matan,
> 
> Thanks for dealing with this.
> 
> On Thu, Feb 08, 2018 at 04:34:12PM +0000, Matan Azrad wrote:
> > Fail-safe PMD uses per sub-device flag called "remove" to indicate the
> > scope where the sub-device isn't synchronized with the fail-safe state.
> >
> > This flag is set when fail-safe gets RMV notification about the
> > physical removal of the sub-device and should be unset when the
> > sub-device completes all the configurations cause it to arrive to the
> > fail-safe state.
> >
> > The previous code wrongly unsets the flag after calling to the
> > sub-device PMD dev_configure() operation and before all the
> > configurations were done.
> >
> > Change the remove flag unsetting to be only after the sub-device
> > successes to arrive to the fail-safe state.
> >
> 
> I'm not sure this is the right way to do this.
> I think it's clear that it was a mistake to set sdev->remove to 0 only during
> fs_dev_configure.
> 
> The flag itself only means "there is something to be done on this device,
> please clean up".
> 
> Once the clean-up has happened, then the flag is not necessary anymore
> and should be reset.
> 
> So I thought that this fix would actually put the flag reset within
> fs_dev_remove, right before reinstalling the hotplug alarm.
> 
> At this point, the device state would have been set back to DEV_UNDEFINED,
> so the remove flag is unnecessary for any operation trying to avoid
> unplugged slaves.
> 
> The "remove" flag is initialized at 0 when sub-devices are allocated (during
> fail-safe init). This means that there would be a difference in the state of the
> slave between its first initialization and any subsequent init, after one
> successful plugout.
> 

But what's about plug-in process?
Do you want to allow control commands for a sub-device while it is plugging-in?

Unset the remove flag in fs_dev_remove allows to control commands to occur in parallel to plug in process.  

Maybe the name of the flag should be changed to unsynchronized.

> > Fixes: a46f8d5 ("net/failsafe: add fail-safe PMD")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Matan Azrad <matan@mellanox.com>
> > ---
> >  drivers/net/failsafe/failsafe_ether.c | 2 ++
> >  drivers/net/failsafe/failsafe_ops.c   | 2 +-
> >  2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/failsafe/failsafe_ether.c
> > b/drivers/net/failsafe/failsafe_ether.c
> > index 4c6e938..ca42376 100644
> > --- a/drivers/net/failsafe/failsafe_ether.c
> > +++ b/drivers/net/failsafe/failsafe_ether.c
> > @@ -377,6 +377,8 @@
> >  				      i);
> >  				goto err_remove;
> >  			}
> > +			if (PRIV(dev)->state < DEV_STARTED)
> > +				sdev->remove = 0;
> 
> Here the remove flag should already be 0. If it isn't, this is a
> (logical) bug, which should be properly addressed instead of patched in this
> way.

Same answer as above.

> >  		}
> >  	}
> >  	/*
> > diff --git a/drivers/net/failsafe/failsafe_ops.c
> > b/drivers/net/failsafe/failsafe_ops.c
> > index 7a67e16..a7c2dba 100644
> > --- a/drivers/net/failsafe/failsafe_ops.c
> > +++ b/drivers/net/failsafe/failsafe_ops.c
> > @@ -131,7 +131,6 @@
> >  			dev->data->dev_conf.intr_conf.lsc = 0;
> >  		}
> >  		DEBUG("Configuring sub-device %d", i);
> > -		sdev->remove = 0;
> 
> This is correct.
> 
> >  		ret = rte_eth_dev_configure(PORT_ID(sdev),
> >  					dev->data->nb_rx_queues,
> >  					dev->data->nb_tx_queues,
> > @@ -197,6 +196,7 @@
> >  			return ret;
> >  		}
> >  		sdev->state = DEV_STARTED;
> > +		sdev->remove = 0;
> 
> This seems unnecessary, if this operation was already performed once the
> device has been properly removed.

Same answer as above.
 
> >  	}
> >  	if (PRIV(dev)->state < DEV_STARTED)
> >  		PRIV(dev)->state = DEV_STARTED;
> > --
> > 1.8.3.1
> >
> 
> --
> Gaëtan Rivet
> 6WIND

  reply	other threads:[~2018-02-08 19:03 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-09 19:27 [dpdk-dev] [PATCH] net/failsafe: fix calling device during RMV events Ophir Munk
2017-09-11  8:31 ` Gaëtan Rivet
2017-09-23 21:57   ` Ophir Munk
2017-10-05 22:42     ` [dpdk-dev] [PATCH v3] " Ophir Munk
2017-10-20 10:35       ` Gaëtan Rivet
2017-10-23  7:17         ` Ophir Munk
2017-10-23  8:36           ` Gaëtan Rivet
2017-11-29 19:17             ` [dpdk-dev] [dpdk-stable] " Ferruh Yigit
2018-01-18 22:22               ` Thomas Monjalon
2018-01-18 23:35                 ` Gaëtan Rivet
2018-02-08 12:20       ` [dpdk-dev] [PATCH v4 0/2] failsafe: " Matan Azrad
2018-02-08 12:20         ` [dpdk-dev] [PATCH v4 1/2] net/failsafe: fix hotplug alarm cancel Matan Azrad
2018-02-08 12:20         ` [dpdk-dev] [PATCH v4 2/2] net/failsafe: fix calling device during RMV events Matan Azrad
2018-02-08 16:34         ` [dpdk-dev] [PATCH v5 0/3] failsafe: " Matan Azrad
2018-02-08 16:34           ` [dpdk-dev] [PATCH v5 1/3] net/failsafe: fix hotplug alarm cancel Matan Azrad
2018-02-08 16:34           ` [dpdk-dev] [PATCH v5 2/3] net/failsafe: fix removal scope Matan Azrad
2018-02-08 17:19             ` Gaëtan Rivet
2018-02-08 19:03               ` Matan Azrad [this message]
2018-02-08 16:34           ` [dpdk-dev] [PATCH v5 3/3] net/failsafe: fix calling device during RMV events Matan Azrad
2018-02-08 18:11             ` Gaëtan Rivet
2018-02-08 19:24               ` Matan Azrad
2018-02-11 17:24           ` [dpdk-dev] [PATCH v6 0/3] failsafe: fix hotplug races Matan Azrad
2018-02-11 17:24             ` [dpdk-dev] [PATCH v6 1/3] net/failsafe: fix hotplug alarm cancel Matan Azrad
2018-02-11 17:24             ` [dpdk-dev] [PATCH v6 2/3] net/failsafe: fix removal scope Matan Azrad
2018-02-11 17:24             ` [dpdk-dev] [PATCH v6 3/3] net/failsafe: fix hotplug races Matan Azrad
2018-02-12 18:33               ` Gaëtan Rivet
2018-02-12 20:35                 ` Matan Azrad
2018-02-12 20:51             ` [dpdk-dev] [PATCH v7 0/3] failsafe: " Matan Azrad
2018-02-12 20:51               ` [dpdk-dev] [PATCH v7 1/3] net/failsafe: fix hotplug alarm cancel Matan Azrad
2018-02-12 20:51               ` [dpdk-dev] [PATCH v7 2/3] net/failsafe: fix removal scope Matan Azrad
2018-02-12 20:51               ` [dpdk-dev] [PATCH v7 3/3] net/failsafe: fix hotplug races Matan Azrad
2018-02-13 13:31               ` [dpdk-dev] [PATCH v7 0/3] failsafe: " Gaëtan Rivet
2018-02-13 16:12                 ` Thomas Monjalon
2018-02-13 20:58                   ` De Lara Guarch, Pablo
2018-02-13 21:13                     ` Matan Azrad
2018-02-13 21:21                       ` Thomas Monjalon

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=AM4PR0501MB265749F33C515836EA2A4211D2F30@AM4PR0501MB2657.eurprd05.prod.outlook.com \
    --to=matan@mellanox.com \
    --cc=dev@dpdk.org \
    --cc=gaetan.rivet@6wind.com \
    --cc=ophirmu@mellanox.com \
    --cc=stable@dpdk.org \
    /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).