From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jiri Pirko <jiri@resnulli.us>
Subject: Re: [PATCH RFC net-next 00/19] Devlink health reporting and recovery
 system
Date: Fri, 4 Jan 2019 10:12:10 +0100
Message-ID: <20190104091210.GC21274@nanopsycho.orion>
References: <1546266733-9512-1-git-send-email-eranbe@mellanox.com>
 <20181231174727.6280fc3c@cakuba.hsd1.ca.comcast.net>
 <6eb2ebe0-40fa-f037-f0f4-d54c907da185@mellanox.com>
 <20190102144629.525d7dc1@cakuba.hsd1.ca.comcast.net>
 <44d02f4d-f5c9-a5dd-9392-97e1268f5371@mellanox.com>
 <20190103142834.7e86c2d1@cakuba.netronome.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Eran Ben Elisha <eranbe@mellanox.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "David S. Miller" <davem@davemloft.net>,
        Jiri Pirko <jiri@mellanox.com>,
        Moshe Shemesh <moshe@mellanox.com>,
        Aya Levin <ayal@mellanox.com>, Tal Alon <talal@mellanox.com>,
        Ariel Almog <ariela@mellanox.com>
To: Jakub Kicinski <jakub.kicinski@netronome.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-wr1-f68.google.com ([209.85.221.68]:32803 "EHLO
        mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1725913AbfADJUW (ORCPT
        <rfc822;netdev@vger.kernel.org>); Fri, 4 Jan 2019 04:20:22 -0500
Received: by mail-wr1-f68.google.com with SMTP id c14so36053152wrr.0
        for <netdev@vger.kernel.org>; Fri, 04 Jan 2019 01:20:20 -0800 (PST)
Content-Disposition: inline
In-Reply-To: <20190103142834.7e86c2d1@cakuba.netronome.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

Thu, Jan 03, 2019 at 11:28:34PM CET, jakub.kicinski@netronome.com wrote:
>On Thu, 3 Jan 2019 13:31:59 +0000, Eran Ben Elisha wrote:
>> Arch wise those are two different features which we shouldn't mix.
>> The region dump is aiming at dumping of information for monitoring of 
>> "HW memory" at real time, more like a dumb channel to provide memory 
>> chunks from HW to user.
>
>The "real time read" part of the region dump was not even implemented.
>And it was the part that made most sense to me.

Agreed. I believe that it was planned to be used for mlx5.


>
>Region snapshots were described as a tool for gathering crash dumps.
>See bedc989b0c98 ("net/mlx4_core: Add Crdump FW snapshot support").
>
>The "chunks from HW" is also incorrect as (1) current implementation of
>regions seem to mostly revolve around FW state and (2) there is nothing
>in the man page etc. that says HW.
>
>I'm not saying region snapshots fit the bill perfectly for you, I'm
>saying you guys are adding a second facility to do a very similar thing
>in the span of 6 months - how is it unreasonable of me to ask to
>consolidate?

If we would need to push binary, yes. But as I described in another
email, that is not the case.

>
>But I'm not gonna fight you any more on this, if nobody else cares.