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 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) 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=/H5Pt+CusarAk76ZwmOGc2kVvUeJL/LN0zuX3/qto7M=; b=Rpkz0+az+mZDJBYuqPbDb9OcXjsmlXTHtiIeajMM8rTCf6GJwjM8ozBGCsT1shA6gK rOUuia+qdy5CNpU+PQdERjT0dw8KwSyL9ueNEu8GRN5NzYAtpmgguCdf0RllfAy9aO1R Msqk9kENr2MUo7vxsjcH0PA6CMSIQnlhxKwsxshJiGAoySpMxWYNxfFlcy03quX0YCgA apFMrvcEgH+VcUwTGkfPEkUgu9pChcyWoJvst/Nk2zFgwSVjbhS5kQWEJm2Mo8diYjQ8 5PumkF/LjO8MuYGDkeYI1UqIEeO+b1VBSUCBfWqUFCdCnw11YH8dKnfBtLJNaG+XqRei svUA== 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=/H5Pt+CusarAk76ZwmOGc2kVvUeJL/LN0zuX3/qto7M=; b=moFkfrAyGTVd1Baptbtl7N9vtb9xN4svdVxHjEBSHomnmsC2kvzsRNeeF+dALEcARu 8ZHUA/mlxKxRAM5QivJMs6xJSBPszf3QPcDWswwRkLvRJ1D361Lg3m/6Y4HY9OSni6XJ e3t8BxN1Tur5/vAGZvJB7ZitbVSZlaHzPaTrVSbxZTCjXZcBOwBd5h5fEM8bAkxQJ0N2 BbJa24uXG7gOdqYfpsgYCo97RZcw3ndVOSLd3KiAMmH6f0C0Yu0raQrIgi7wUX2gEqHQ K2g621KPtPiy+rytXdDu4EfluLjVjfYrPMjl1tndIczWxU9VsJIjw3eG5lfWJ7K3YLXJ tJYA== X-Gm-Message-State: AKwxytcWKcQTaK3lhdFehCH/y89rDrbBd/C74mkC54eSmGzbhQ7Z31HV IMtQV/5idKYkjLZ415xklqltuA== X-Google-Smtp-Source: ACJfBotVoslJBJUN9ALYISy2hpPCfgs1Ade7nk+reHpSjZgBF25jMfEjOLGN576brEs53xKVVHUuUw== X-Received: by 10.28.152.74 with SMTP id a71mr5159357wme.76.1515592061214; Wed, 10 Jan 2018 05:47:41 -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 b8sm23201228wma.2.2018.01.10.05.47.39 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 10 Jan 2018 05:47:40 -0800 (PST) Date: Wed, 10 Jan 2018 14:47:22 +0100 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Matan Azrad Cc: Thomas Monjalon , dev@dpdk.org 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1515587465-9304-7-git-send-email-matan@mellanox.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v4 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: Wed, 10 Jan 2018 13:47:41 -0000 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