From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id 9C2D31B04C for ; Mon, 8 Jan 2018 11:57:52 +0100 (CET) Received: by mail-wm0-f41.google.com with SMTP id b76so13477947wmg.1 for ; Mon, 08 Jan 2018 02:57:52 -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=q04arva2VQWEoqbYKAFxuDGyRJV9Mt9YuRDA4MF1KL4=; b=YG63JauKasM34KJ0XEP1rlVl/6firfkGUo1Ribl5mNiosCGHbwaWtsn9j96cfL+cTp CnULjuDH3F916XI+hiepfAUcPanKr8IozHCfEaIWcIj5Lse1qEnkLDg/+qOKpZI7JRq7 J2sRRrJ6D+x2HCUt1orywN3SMHDD1erHFunxxElv8Xa04Q0zZGOgTG4LygI5KPL/nwsK 06qm2U2cUmFah2T4RmD4LsAECCky7IrB6xTmR1ou9Mwx34w3bB4V3x/XOtJHyJlIirjB sWWtdpDmL5bAEu8+bSG1dM7KdItenKk/2yNZj53OzVjWNHFEFTLE3wXSznnbifsZVczG IiFg== 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=q04arva2VQWEoqbYKAFxuDGyRJV9Mt9YuRDA4MF1KL4=; b=uO4DGp5dJ+yPzUIxr74FFAvV0xJLwvlZg1pyZHT1X9FuEwwotm93Jiru1EyiiABBP0 +H7Aus6WRdrT4EWcvUwYuZsX8Kut4gDbBMT4FiAUhwZW0dgYBg+wH860Yz2e1yUgSIvd GDeZLThttVRM/TEu81/ZmShzJkNqGmv36FCeGyr2KLVyw2wIOHZxidRYhnbNIaY6Hi// w6H1DVSpjbLIps006D98Zz4NjLZx14Qu9xJLYO0PvxyCgOfja0x+VktZoM+uISW7bUT9 WtTSW3P2oKjuCfmryhu2k1xwBIfTMkdzvowxLKts7MirArkYJcWAVYq7c2RRfBibGuFX urIQ== X-Gm-Message-State: AKGB3mKM6ZLPyzkYstsCLFSI3O+CzB/8oRTh4c4VS09t7wXoFQj8gNpM 2RFcmNTd0sQl6IJSedDPE897+Q== X-Google-Smtp-Source: ACJfBot5tc2PGwFH80h8S2Jg99+Rz8ck63aHMc0IXgFwZoEDSlKU12gZJiN4ibehoyx48YDNSpDbsQ== X-Received: by 10.28.210.149 with SMTP id j143mr8198319wmg.48.1515409072224; Mon, 08 Jan 2018 02:57:52 -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 m133sm14957103wmd.40.2018.01.08.02.57.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 Jan 2018 02:57:51 -0800 (PST) Date: Mon, 8 Jan 2018 11:57:39 +0100 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Matan Azrad Cc: Adrien Mazarguil , Thomas Monjalon , "dev@dpdk.org" Message-ID: <20180108105739.qkyejshupojkwyv2@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> <20171219222131.plcfn5wqggyn5znw@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-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: Mon, 08 Jan 2018 10:57:52 -0000 Hi Matan, Sorry for the delay on this. On Wed, Dec 20, 2017 at 10:58:29AM +0000, Matan Azrad wrote: > Hi Gaetan > > > -----Original Message----- > > From: Gaëtan Rivet [mailto:gaetan.rivet@6wind.com] > > Sent: Wednesday, December 20, 2017 12:22 AM > > To: Matan Azrad > > Cc: Adrien Mazarguil ; Thomas Monjalon > > ; dev@dpdk.org > > Subject: Re: [PATCH v3 6/6] net/failsafe: fix removed device handling > > > > 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") As stated previously, please do not include those fixes lines. > > > > > > 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? > > > > I think that there is a real different between eth_err function to fs_is_error: > ethdev uses eth_err function to adjust removal return value to be -EIO. > fail-safe uses fs_is_error function to check if an error should be reported to the user to save the fail-safe principle that the app should not be aware of device removal - this is the main idea that also causes me to change the name from fs_is_removed to fs_is_error. I would have preferred if it followed the same pattern as ethdev (that function be used to adjust the return value, not performing a flag check). While better on its own, the pattern: if (fs_is_error(sdev, err)) { ERROR("xxxx"); return err; } is dangerous, as then the author is forbidden from returning err, assuming err could be -EIO. He or she would be forced to return an explicit "0". To be clear, here would be an easy mistake to do: if (fs_is_error(sdev, err)) { ERROR("xxxx"); } return err; And this kind of code-flow is not unusual, or even unwanted. I dislike having this kind of implicit rule derived from using a helper such as fs_is_error(). The alternative if ((err = fs_err(sdev, err))) { ERROR("xxxx"); return err; } Forces the value err to be set to the correct one. This mistake can already be found in your patch: > @@ -150,7 +150,7 @@ > continue; > local_ret = rte_flow_destroy(PORT_ID(sdev), > flow->flows[i], error); > - if (local_ret) { > + if (fs_is_error(sdev, local_ret)) { > ERROR("Failed to destroy flow on sub_device %d: %d", > i, local_ret); > if (ret == 0) Your environment does not include the function, but this is within fs_flow_destroy (please update to include the context by the way it helps a lot the review :). Afterward, line 162 ret is directly used as return value. Also, fs_err() would need to transform rte_errno when relevant (mostly in failsafe_flow.c I think). This is the kind of subtlety that needs to be avoided when designing APIs, even internal ones. This will induce errors afterward and complicate the maintenance of the codebase. Best regards, -- Gaëtan Rivet 6WIND