From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet Subject: Re: [PATCH v4 6/6] net/failsafe: fix removed device handling Date: Wed, 10 Jan 2018 14:47:22 +0100 Message-ID: <20180110134722.eowt2gy5bmac4thx@bidouze.vm.6wind.com> References: <1513703415-29145-1-git-send-email-matan@mellanox.com> <1515587465-9304-1-git-send-email-matan@mellanox.com> <1515587465-9304-7-git-send-email-matan@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Thomas Monjalon , dev@dpdk.org To: Matan Azrad 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 C51CF1B1FA for ; Wed, 10 Jan 2018 14:47:41 +0100 (CET) Received: by mail-wm0-f65.google.com with SMTP id f206so27135227wmf.5 for ; Wed, 10 Jan 2018 05:47:41 -0800 (PST) Content-Disposition: inline In-Reply-To: <1515587465-9304-7-git-send-email-matan@mellanox.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Matan, I am a bit concerned with the forceful rte_errno reset within fs_err, I think it would have been safer to only do this when rte_errno is modified by the eth_dev ops (either in rte_flow or another library). This means that the eth_dev API will be slightly different whether the ethdev is a fail-safe or a bare device, which might throw off some users. One could read the eth_dev source and not see any rte_errno change, and wonder why it is modified on some specific ports. But this is pretty minor, and if problem arises it will be easy to pinpoint and fix, so I won't bother you further on this patch. Thanks for the good work. On Wed, Jan 10, 2018 at 12:31:05PM +0000, Matan Azrad wrote: > There is time between the physical removal of the device until > sub-device PMDs get a RMV interrupt. At this time DPDK PMDs and > applications still don't know about the removal and may call sub-device > control operation which should return an error. > > In previous code this error is reported to the application contrary to > fail-safe principle that the app should not be aware of device removal. > > Add an removal check in each relevant control command error flow and > prevent an error report to application when the sub-device is removed. > > Signed-off-by: Matan Azrad Acked-by: Gaetan Rivet > --- > drivers/net/failsafe/failsafe_flow.c | 18 ++++++++++------- > drivers/net/failsafe/failsafe_ops.c | 35 ++++++++++++++++++++++----------- > drivers/net/failsafe/failsafe_private.h | 11 +++++++++++ > 3 files changed, 46 insertions(+), 18 deletions(-) > -- Gaëtan Rivet 6WIND