Re: [PATCH v2 0/3] devlink region trigger support

From: Jakub Kicinski <kubakici@wp.pl>
To: Yunsheng Lin <linyunsheng@huawei.com>
Cc: Alex Vesker <valex@mellanox.com>,
	Jacob Keller <jacob.e.keller@intel.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"jiri@resnulli.us" <jiri@resnulli.us>
Subject: Re: [PATCH v2 0/3] devlink region trigger support
Date: Mon, 13 Jan 2020 03:34:31 -0800	[thread overview]
Message-ID: <20200113033431.1d32dcbe@cakuba> (raw)
In-Reply-To: <421f78c2-7713-b931-779e-dfe675fe5f53@huawei.com>

On Mon, 13 Jan 2020 09:39:50 +0800, Yunsheng Lin wrote:
> On 2020/1/13 5:18, Alex Vesker wrote:
> > On 1/12/2020 10:45 PM, Jakub Kicinski wrote:  
> >> I think there is a fundamental difference between health API and
> >> regions in the fact that health reporters allow for returning
> >> structured data from different sources which are associated with 
> >> an event/error condition. That includes information read from the
> >> hardware or driver/software state. Region API (as Jake said) is good
> >> for dumping arbitrary addressable content, e.g. registers. I don't see
> >> much use for merging the two right now, FWIW...  
> 
> The point is that we are beginning to use health API for event/error
> condition, right? Do we use health API or regions API to dump a arbitrary
> addressable content when there is an event/error detected?
> 
> Also we may need to dump both a arbitrary addressable content and the

If the information dumped is pertinent in the context of a health event
it's not arbitrary.

> structured data when there is an event/error detected, the health API or
> regions API can not do both, right?

I think for errors and events health API will be more suitable 99% of
the time.

> It still seems it is a little confusing when deciding to use health or
> regions API.
>
> > Totally agree with Jakub, I think health and region are different and
> > each has its
> > usages as mentioned above. Using words such as recovery and health for
> > exposing
> > registers doesn't sound correct. There are future usages I can think of
> > for region if we
> > will add the trigger support as well as the live region read.  
> 
> health API already has "trigger support" now if region API is merged to
> health API.
> 
> I am not sure I understand "live region" here, what is the usecase of live
> region?

Reading registers of a live system without copying them to a snapshot
first. Some chips have so many registers it's impractical to group them
beyond "registers of IP block X", if that. IMHO that fits nicely with
regions, health is grouped by event, so we'd likely want to dump for
example one or two registers from the MAC there, while the entire set
of MAC registers can be exposed as a region.