All of lore.kernel.org
 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>, Ophir Munk <ophirmu@mellanox.com>,
	"stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [PATCH v2 1/2] net/failsafe: fix removed sub-device cleanup
Date: Tue, 22 May 2018 10:19:14 +0000	[thread overview]
Message-ID: <VI1PR0501MB26084A10DC57B449B220C5D4D2940@VI1PR0501MB2608.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <20180522085656.bx3r3e4c6lz4xwlp@bidouze.vm.6wind.com>

Hi Gaetan

From: Gaëtan Rivet
> Hello Matan,
> 
> On Mon, May 21, 2018 at 07:48:03PM +0000, Matan Azrad wrote:
> > The fail-safe PMD registers to RMV event for each removable sub-device
> > port in order to cleanup the sub-device resources and switch the Tx
> > sub-device directly when it is plugged-out.
> >
> > During removal time, the fail-safe PMD stops and closes the sub-device
> > but it doesn't unregister the LSC and RMV callbacks of the sub-device
> > port.
> >
> > It can lead the callbacks to be called for a port which is no more
> > associated with the fail-safe sub-device, because there is not a
> > guarantee that a sub-device gets the same port ID for each plug-in
> > process. This port, for example, may belong to another sub-device of a
> > different fail-safe device.
> >
> > Unregister the LSC and RMV callbacks for sub-devices which are not
> > used.
> >
> > Fixes: 598fb8aec6f6 ("net/failsafe: support device removal")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Matan Azrad <matan@mellanox.com>
> > ---
> >  drivers/net/failsafe/failsafe_ether.c   | 22 ++++++++++++++++++++++
> >  drivers/net/failsafe/failsafe_ops.c     |  5 +++++
> >  drivers/net/failsafe/failsafe_private.h |  5 +++++
> >  3 files changed, 32 insertions(+)
> >
> > V2:
> > Improve the commit log and add code comments for the new sub-dev fields
> (Ophir suggestion).
> >
> >
> > diff --git a/drivers/net/failsafe/failsafe_ether.c
> > b/drivers/net/failsafe/failsafe_ether.c
> > index 733e95d..2bbee82 100644
> > --- a/drivers/net/failsafe/failsafe_ether.c
> > +++ b/drivers/net/failsafe/failsafe_ether.c
> > @@ -260,6 +260,7 @@
> >  		sdev->state = DEV_ACTIVE;
> >  		/* fallthrough */
> >  	case DEV_ACTIVE:
> > +		failsafe_eth_dev_unregister_callbacks(sdev);
> >  		rte_eth_dev_close(PORT_ID(sdev));
> >  		sdev->state = DEV_PROBED;
> >  		/* fallthrough */
> > @@ -321,6 +322,27 @@
> >  }
> >
> >  void
> > +failsafe_eth_dev_unregister_callbacks(struct sub_device *sdev) {
> > +	if (sdev == NULL)
> > +		return;
> > +	if (sdev->rmv_callback) {
> > +		rte_eth_dev_callback_unregister(PORT_ID(sdev),
> > +					RTE_ETH_EVENT_INTR_RMV,
> > +					failsafe_eth_rmv_event_callback,
> > +					sdev);
> > +		sdev->rmv_callback = 0;
> 
> I agree with Ophir here, either the return value should not be ignored, and
> rmv_callback should only be set to 0 on success, or a proper justification (and
> an accompanying comment) should be given.
> 
> The issue I could see is that even on error, there won't be a process to try again
> unregistering the callback.
> 
> Maybe this could be added in failsafe_dev_remove()? Something like
> 
> FOREACH_SUBDEV(sdev, i, dev) {
>     if (sdev->rmv_callback && sdev->state <= DEV_PROBED)
>         if (rte_eth_dev_callback_unregister(...) == 0)
>             sdev->rmv_callback = 0;
>     /* same for lsc_callback */
> }
> 
> Does it make sense to you? Do you think this is necessary, or should we ignore
> this?

The RMV\LSC event callbacks are called from the host thread and also the removal process is running from the host thread so I think EAGAIN is not expected in the removal time.
Other error (EINVAL) may return again every attempt and probably points to another critical issue.

Is a code comment for the above enough? Or you think we still need to check it?


> Thanks,
> --
> Gaëtan Rivet
> 6WIND

  reply	other threads:[~2018-05-22 10:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-17 18:52 [PATCH 1/2] net/failsafe: fix removed sub-device cleanup Matan Azrad
2018-05-17 18:52 ` [PATCH 2/2] net/failsafe: fix duplicate event registraton Matan Azrad
2018-05-21 18:13 ` [PATCH 1/2] net/failsafe: fix removed sub-device cleanup Ophir Munk
2018-05-21 19:48 ` [PATCH v2 " Matan Azrad
2018-05-21 19:48   ` [PATCH v2 2/2] net/failsafe: fix duplicate event registration Matan Azrad
2018-05-22  8:56   ` [PATCH v2 1/2] net/failsafe: fix removed sub-device cleanup Gaëtan Rivet
2018-05-22 10:19     ` Matan Azrad [this message]
2018-05-22 11:53       ` Gaëtan Rivet
2018-05-22 12:09         ` Matan Azrad
2018-05-22 12:38   ` [PATCH v3 " Matan Azrad
2018-05-22 12:38     ` [PATCH v3 2/2] net/failsafe: fix duplicate event registration Matan Azrad
2018-05-22 13:15       ` Gaëtan Rivet
2018-05-22 13:14     ` [PATCH v3 1/2] net/failsafe: fix removed sub-device cleanup Gaëtan Rivet
2018-05-22 13:59       ` [dpdk-stable] " 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=VI1PR0501MB26084A10DC57B449B220C5D4D2940@VI1PR0501MB2608.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 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.