From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Pirko Subject: Re: [RFC PATCH iproute2-next V2] System specification exception API Date: Thu, 27 Sep 2018 16:34:32 +0200 Message-ID: <20180927143432.GD2209@nanopsycho.orion> References: <1537962779-8910-1-git-send-email-eranbe@mellanox.com> <20180927124736.GB2209@nanopsycho.orion> <8a064f7f-298e-9cbe-d58a-fdf3d79eef24@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netdev@vger.kernel.org, Jakub Kicinski , Jiri Pirko , Stephen Hemminger , Andrew Lunn , "Tobin C. Harding" , Ariel Almog , Tal Alon To: Eran Ben Elisha Return-path: Received: from mail-wr1-f51.google.com ([209.85.221.51]:43771 "EHLO mail-wr1-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727280AbeI0U55 (ORCPT ); Thu, 27 Sep 2018 16:57:57 -0400 Received: by mail-wr1-f51.google.com with SMTP id z14-v6so2886978wrs.10 for ; Thu, 27 Sep 2018 07:39:21 -0700 (PDT) Content-Disposition: inline In-Reply-To: <8a064f7f-298e-9cbe-d58a-fdf3d79eef24@mellanox.com> Sender: netdev-owner@vger.kernel.org List-ID: Thu, Sep 27, 2018 at 04:02:48PM CEST, eranbe@mellanox.com wrote: > > >On 9/27/2018 3:47 PM, Jiri Pirko wrote: >> Wed, Sep 26, 2018 at 01:52:58PM CEST, eranbe@mellanox.com wrote: >> > The exception spec is targeted for Real Time Alerting, in order to know when >> > something bad had happened to a PCI device >> > - Provide alert debug information >> > - Self healing >> > - If problem needs vendor support, provide a way to gather all needed debugging >> > information. >> > >> > The exception mechanism contains condition checkers which sense for malfunction. Upon a condition hit, >> > actions such as logs and correction can be taken. >> > >> > The condition checkers are divided into the following groups >> > - Hardware - a checker which is triggered by the device due to >> > malfunction. >> > - Software - a checker which is triggered by the software due to >> > malfunction. >> >> What do you mean by a "software malfunction", a "FW malfunction"? >> Also, I don't see this 2 groups in the man. > >Software malfunction can be a Transmit error (caused by bad send request). Sorry, but I still don't undestand what "software malfuntion" are you talking about. Could you be more specific please? >FW/HW malfunction can be any catastrophic error report (the ones that should >be exposed to driver). >The comment here was to highlight that we can support different kinds of >condition groups. >If for a specific condition, we will need to highlight it is SW/HW, we can >concatenate it to its name. > >Eran > >> >> >> > Both groups of condition checkers can be triggered due to error event or due to a periodic check. >> > >> > Actions are the way to handle those events. Action can be in one of the >> > following groups: >> > - Dump - SW trace, SW dump, HW trace, HW dump >> > - Reset - Surgical correction (e.g. modify Q, flush Q, reset of device, etc) >> > Actions can be performed by SW or HW. >> > >> > User is allowed to enable or disable condition checkers and its action mapping. >> > >> > This RFC man page patch describes the suggested API of devlink-exception in order >> > to control conditions and actions. >> > >> > V2: >> > * Renaming terms: >> > health -> exception >> > sensor -> condition >> > * Remove reinit command and merge with action command. >> > * Consmetics in grammer. >> > >> > Eran Ben Elisha (1): >> > man: Add devlink exception man page >> > >> > man/man8/devlink-exception.8 | 158 +++++++++++++++++++++++++++++++++++++++++++ >> > 1 file changed, 158 insertions(+) >> > create mode 100644 man/man8/devlink-exception.8 >> > >> > -- >> > 1.8.3.1 >> >