From: Leon Romanovsky <leon@kernel.org>
To: "wangjie (L)" <wangjie125@huawei.com>
Cc: Hao Lan <lanhao@huawei.com>,
davem@davemloft.net, kuba@kernel.org, yisen.zhuang@huawei.com,
salil.mehta@huawei.com, edumazet@google.com, pabeni@redhat.com,
richardcochran@gmail.com, shenjian15@huawei.com,
netdev@vger.kernel.org
Subject: Re: [PATCH net-next 2/2] net: hns3: add vf fault process in hns3 ras
Date: Mon, 6 Feb 2023 15:36:30 +0200 [thread overview]
Message-ID: <Y+ECXjVqA316k+Sf@unreal> (raw)
In-Reply-To: <d23688f8-ca8e-cfa5-7fad-517810bee433@huawei.com>
On Thu, Feb 02, 2023 at 09:08:37PM +0800, wangjie (L) wrote:
>
>
> On 2023/1/31 21:24, Leon Romanovsky wrote:
> > On Tue, Jan 31, 2023 at 08:04:14PM +0800, wangjie (L) wrote:
> > >
> > >
> > > On 2023/1/21 1:12, Leon Romanovsky wrote:
> > > > On Wed, Jan 18, 2023 at 08:34:03PM +0800, wangjie (L) wrote:
> > > > >
> > > > >
> > > > > On 2023/1/17 19:21, Leon Romanovsky wrote:
> > > > > > On Tue, Jan 17, 2023 at 03:04:15PM +0800, wangjie (L) wrote:
> > > > > > >
> > > > > > >
> > > > > > > On 2023/1/13 14:51, Leon Romanovsky wrote:
> > > > > > > > On Fri, Jan 13, 2023 at 10:08:29AM +0800, Hao Lan wrote:
> > > > > > > > > From: Jie Wang <wangjie125@huawei.com>
> > > > > > > > >
> > > > > > > > > Currently hns3 driver supports vf fault detect feature. Several ras caused
> > > > > > > > > by VF resources don't need to do PF function reset for recovery. The driver
> > > > > > > > > only needs to reset the specified VF.
> > > > > > > > >
> > > > > > > > > So this patch adds process in ras module. New process will get detailed
> > > > > > > > > information about ras and do the most correct measures based on these
> > > > > > > > > accurate information.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Jie Wang <wangjie125@huawei.com>
> > > > > > > > > Signed-off-by: Hao Lan <lanhao@huawei.com>
> > > > > > > > > ---
> > > > > > > > > drivers/net/ethernet/hisilicon/hns3/hnae3.h | 1 +
> > > > > > > > > .../hns3/hns3_common/hclge_comm_cmd.h | 1 +
> > > > > > > > > .../hisilicon/hns3/hns3pf/hclge_err.c | 113 +++++++++++++++++-
> > > > > > > > > .../hisilicon/hns3/hns3pf/hclge_err.h | 2 +
> > > > > > > > > .../hisilicon/hns3/hns3pf/hclge_main.c | 3 +-
> > > > > > > > > .../hisilicon/hns3/hns3pf/hclge_main.h | 1 +
> > > > > > > > > 6 files changed, 115 insertions(+), 6 deletions(-)
> > > > > > > >
> > > > > > > > Why is it good idea to reset VF from PF?
> > > > > > > > What will happen with driver bound to this VF?
> > > > > > > > Shouldn't PCI recovery handle it?
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > > .
> > > > > > > PF doesn't reset VF directly. These VF faults are detected by hardware,
> > > > > > > and only reported to PF. PF get the VF id from firmware, then notify the VF
> > > > > > > that it needs reset. VF will do reset after receive the request.
> > > > > >
> > > > > > This description isn't aligned with the code. You are issuing
> > > > > > hclge_func_reset_cmd() command which will reset VF, while notification
> > > > > > are handled by hclge_func_reset_notify_vf().
> > > > > >
> > > > > > It also doesn't make any sense to send notification event to VF through
> > > > > > FW while the goal is to recover from stuck FW in that VF.
> > > > > >
> > > > > Yes, I misunderstand the hclge_func_reset_notify_vf and
> > > > > hclge_func_reset_cmd. It should use hclge_func_reset_notify_vf to inform
> > > > > the VF for recovery. I will fix and retest it in V2.
> > > > >
> > > > > This patch is used to recover specific vf hardware errors, for example the
> > > > > tx queue configuration exceptions. It make sense in these cases for the
> > > > > firmware is still working properly and can do the recovery rightly.
> > > >
> > > > If FW is operational and knows about failure, why can't FW do recovery
> > > > internally to that VF without PF involvement?
> > > I'm sorry to reply so late because I took a vacation. If firmware reset VF
> > > hardware directly without notify the running VF driver, it will cause VF
> > > driver works abnormal.
> >
> > mlx5 health recovery code proves that it is possible to do.
> > Even in your case, FW can notify VF without PF in the middle.
> >
> > Thanks
> >
> These faults only report to PF in hns3 devices, even if devlink health is
> used in hns3 driver, these faults also need to report to PF.
I don't think that it is correct, but let's see your v2 without VF reset
and with PF notifications.
Thanks
>
> Thanks
> > >
> > > Thanks
> > > >
> > > > Thanks
> > > > .
> > > >
> > .
> >
next prev parent reply other threads:[~2023-02-06 13:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-13 2:08 [PATCH net-next 0/2] add some vf fault detect patch for hns Hao Lan
2023-01-13 2:08 ` [PATCH net-next 1/2] net: hns3: add hns3 vf fault detect cap bit support Hao Lan
2023-01-13 2:08 ` [PATCH net-next 2/2] net: hns3: add vf fault process in hns3 ras Hao Lan
2023-01-13 6:51 ` Leon Romanovsky
2023-01-17 7:04 ` wangjie (L)
2023-01-17 11:21 ` Leon Romanovsky
2023-01-18 12:34 ` wangjie (L)
2023-01-20 17:12 ` Leon Romanovsky
2023-01-31 12:04 ` wangjie (L)
2023-01-31 13:24 ` Leon Romanovsky
2023-02-02 13:08 ` wangjie (L)
2023-02-06 13:36 ` Leon Romanovsky [this message]
2023-01-17 8:04 ` Paolo Abeni
2023-01-18 12:36 ` wangjie (L)
2023-01-18 12:36 ` wangjie (L)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y+ECXjVqA316k+Sf@unreal \
--to=leon@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=lanhao@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
--cc=salil.mehta@huawei.com \
--cc=shenjian15@huawei.com \
--cc=wangjie125@huawei.com \
--cc=yisen.zhuang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).