[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190104091210.GC21274@nanopsycho.orion>
Date: Fri, 4 Jan 2019 10:12:10 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc: Eran Ben Elisha <eranbe@...lanox.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Jiri Pirko <jiri@...lanox.com>,
Moshe Shemesh <moshe@...lanox.com>,
Aya Levin <ayal@...lanox.com>, Tal Alon <talal@...lanox.com>,
Ariel Almog <ariela@...lanox.com>
Subject: Re: [PATCH RFC net-next 00/19] Devlink health reporting and recovery
system
Thu, Jan 03, 2019 at 11:28:34PM CET, jakub.kicinski@...ronome.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.
Powered by blists - more mailing lists