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 E0784324B for ; Tue, 19 Dec 2017 23:21:44 +0100 (CET) Received: by mail-wm0-f65.google.com with SMTP id t8so6482096wmc.3 for ; Tue, 19 Dec 2017 14:21:44 -0800 (PST) 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=NwtYN4LotSwQo5sPKHH13Dxa+ufwJ3mKEEiJgmpmIos=; b=nZzNCE19OLTRFgzi8SdeJ+GunqenijeLMGLjAjB7CY68/lzX8vDgeVrvNnUks1Sr5a dT3/JtGIy/aOYzO8QPv2Lyyb6UVogH95P/VT+7iAGF00lEhVFnv2cf2aMLSNd+jimaZE tDXpvI4NXYEO7ywnT57wSaRKrG6KOK9f3L5NTgunl6kQzKThUT13ruoX0gwvM4s/yCgS 3O4gY2m6wcM9tHxm3zG4rTaceWwS6JwbYKznpheIi6pd6H9R3b/XxrOn1ea1FYuD5NgH CgycM8HfE+XCt0azqjtdhwx90yGx+Dbwq2uWxAmpr6hLvEgFCzSDANbUSlIkGmEZl3K1 0thg== 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=NwtYN4LotSwQo5sPKHH13Dxa+ufwJ3mKEEiJgmpmIos=; b=CUxWS9hHsnHKNdQ03H/PdNmIgLShoew+MeHLuv/DbQHNjQSzrI49ZVRO/L/E35rTIo xxkzEn71P6FzkR2+JkEnI1W5b3PzpTWrKJ6wuM/T+xLgXec3bIlzRXVgliANrm3gYHzw mCQt7zY8POKMSYn++L8zbY36UDlmd9bex3dO04sviCtyV7bBufGhSBp7GrYZr0dQYaQV +jf6StlCLspg23r2JbQMj3SH1cICYOqTV0N2lZ/J4lpbrdmVG+NLj2y8TMRrigwFvSQP yvGRU/Dtz00LbKqOyA2pzxNPtlX4WihY0jE0V1vQerwufkXVUn+B955mQiBW96S4jzR+ ohSw== X-Gm-Message-State: AKGB3mI8dQ3heVHgakJVOhU3I0J3p0nS6qEo+LhPE6L8U980sAYGaH1d 6AnV+kyQ0VPitc9s/g75dw6NrQ== X-Google-Smtp-Source: ACJfBosw/dTSOsZrCBdoYR0HO+w8PNN+Ox45N/i+LCjtvcAcwjKF7usalTjLGZLAn9uohUon27+HVw== X-Received: by 10.80.206.26 with SMTP id y26mr2598643edi.117.1513722104512; Tue, 19 Dec 2017 14:21:44 -0800 (PST) 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 h20sm13498707edh.69.2017.12.19.14.21.43 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 19 Dec 2017 14:21:43 -0800 (PST) Date: Tue, 19 Dec 2017 23:21:31 +0100 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Matan Azrad Cc: Adrien Mazarguil , Thomas Monjalon , dev@dpdk.org Message-ID: <20171219222131.plcfn5wqggyn5znw@bidouze.vm.6wind.com> References: <1513175370-16583-1-git-send-email-matan@mellanox.com> <1513703415-29145-1-git-send-email-matan@mellanox.com> <1513703415-29145-7-git-send-email-matan@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1513703415-29145-7-git-send-email-matan@mellanox.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v3 6/6] net/failsafe: fix removed device handling X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 22:21:45 -0000 Hi Matan, On Tue, Dec 19, 2017 at 05:10:15PM +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. > > Fixes: a46f8d5 ("net/failsafe: add fail-safe PMD") > Fixes: b737a1e ("net/failsafe: support flow API") > > Signed-off-by: Matan Azrad > --- > +/* > + * Check if error should be reported to the user. > + */ > +static inline bool > +fs_is_error(struct sub_device *sdev, int err) > +{ > + /* A device removal shouldn't be reported as an error. */ > + if (err == 0 || sdev->remove == 1 || err == -EIO) > + return false; > + return true; > +} This is better, thanks. However is there a reason you did not follow the same pattern as ethdev with eth_err? I see the two functions as similar in their intent, making them close to each other would be clearer to a reader being familiar with the ethdev API and that would be interested in fail-safe. What do you think? -- Gaëtan Rivet 6WIND