From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f65.google.com (mail-wm0-f65.google.com [74.125.82.65]) by dpdk.org (Postfix) with ESMTP id 2CE16231E for ; Tue, 22 May 2018 13:53:25 +0200 (CEST) Received: by mail-wm0-f65.google.com with SMTP id a8-v6so31062250wmg.5 for ; Tue, 22 May 2018 04:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=ebjaS6RlSXoExYTM65FHTlykTqT/J1peaDNUkdz7Is4=; b=AK87TS95eaSC+E6pjfFMmmeF1lXZLp8jzo5DcUL08W6jsPZRlztlpD3norJsbpH16P TSsm3vCtYeJHIj2oMcPPQqEX5bdc0xfCgpR4XKwFwRxj94pkh6379ktk8CTmASOlYq2n kaqLNSWKWeTvcm4491EiZcpl0Y6CzA7fxxiqiUBBAaBYoChm3ZXJk5SJNfEohObpp18K 3a4vehBru1aME5bLDFOMrx7we8d78+JT1t2Qx7YrGyXoQdbmucGyhCRQ+EqJ4KXUQQMZ KH18wZCdR6e4U4vZv1UkUPskVj7KkE1N+6mQ2drNMsXgMsKNLtMHggtIS0gAyCVsmeJo XQNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=ebjaS6RlSXoExYTM65FHTlykTqT/J1peaDNUkdz7Is4=; b=VjugaemS4esQ5uDoeeJ14sp7vkqawNzm/mmrWNfIt1ye6G7yHPezLU1uiugWXYFpJE FkYfQSZG+2okZBk8iCurj21q5vW3kIReLmF1CES2XvAUmqgefh3A5fONd2gjFvdJ4Djs l0AixGMZONOlM5PFJ41b0cDvpKRdt9h/L75byyAjQ+QhhtI2ZAE/sqPKT4VSaFGV2aua BVjmqPkGV7RFykJqLGTK63I2WpCn8dGYuaZjZtIEzS5CvEJZH5FAbfuXlodKRc9wyljH b0FZYU7sg9VpXouTN8S66X7N24IxIJCktLqdcjAOdOmMTj4WpYrThQ3kJN26Ws74tNel evYg== X-Gm-Message-State: ALKqPwfMYMFGB+/zIZ3PmJHEUxD5UeyhcCm5wTN910sWoAg4R0k/1vQd o545ISdBcuCX1Udux20H+wO/CQ== X-Google-Smtp-Source: AB8JxZpqjh4R7GFE+pAmVMux2jYEgRINdtIKLRNi4IegYDGUqG4pneK4CBkW3iXswyjdpMOmswBHnA== X-Received: by 2002:a1c:4843:: with SMTP id v64-v6mr929935wma.159.1526990004666; Tue, 22 May 2018 04:53:24 -0700 (PDT) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id f15-v6sm5135733wrm.52.2018.05.22.04.53.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 22 May 2018 04:53:23 -0700 (PDT) Date: Tue, 22 May 2018 13:53:08 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Matan Azrad Cc: "dev@dpdk.org" , Ophir Munk , "stable@dpdk.org" Message-ID: <20180522115308.by3cvodasyy4psqt@bidouze.vm.6wind.com> References: <1526583136-21680-1-git-send-email-matan@mellanox.com> <1526932084-1120-1-git-send-email-matan@mellanox.com> <20180522085656.bx3r3e4c6lz4xwlp@bidouze.vm.6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-stable] [PATCH v2 1/2] net/failsafe: fix removed sub-device cleanup X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 11:53:25 -0000 On Tue, May 22, 2018 at 10:19:14AM +0000, Matan Azrad wrote: > 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 > > > --- > > > 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? > > Ok, that makes sense. If EINVAL is possible however, I think a warning would be helpful for the user to be aware of the issue. The callback flag would then be meaningless anyway. -- Gaëtan Rivet 6WIND