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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DB6PR0501MB224859D8DC219E81D4CFB17CC33A0@DB6PR0501MB2248.eurprd05.prod.outlook.com>
Date:   Sun, 12 Jan 2020 21:18:50 +0000
From:   Alex Vesker <valex@...lanox.com>
To:     Jakub Kicinski <kubakici@...pl>,
        Yunsheng Lin <linyunsheng@...wei.com>
CC:     Jacob Keller <jacob.e.keller@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "jiri@...nulli.us" <jiri@...nulli.us>
Subject: Re: [PATCH v2 0/3] devlink region trigger support

On 1/12/2020 10:45 PM, Jakub Kicinski wrote:
> On Sat, 11 Jan 2020 09:51:00 +0800, Yunsheng Lin wrote:
>>> regions can essentially be used to dump arbitrary addressable content. I
>>> think all of the above are great examples.
>>>
>>> I have a series of patches to update and convert the devlink
>>> documentation, and I do provide some further detail in the new
>>> devlink-region.rst file.
>>>
>>> Perhaps you could review that and provide suggestions on what would make
>>> sense to add there?  
>> For the case of region for mlx4, I am not sure it worths the effort to
>> document it, because Jiri has mention that there was plan to convert mlx4 to
>> use "devlink health" api for the above case.
>>
>> Also, there is dpipe, health and region api:
>> For health and region, they seems similar to me, and the non-essential
>> difference is:
>> 1. health can be used used to dump content of tlv style, and can be triggered
>>    by driver automatically or by user manually.
>>
>> 2. region can be used to dump binary content and can be triggered by driver
>>    automatically only.
>>
>> It would be good to merged the above to the same api(perhaps merge the binary
>> content dumping of region api to health api), then we can resue the same dump
>> ops for both driver and user triggering case.
> 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...
>
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.