[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200113183304.GI2131@nanopsycho>
Date: Mon, 13 Jan 2020 19:33:04 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Jacob Keller <jacob.e.keller@...el.com>
Cc: Jakub Kicinski <kubakici@...pl>,
Yunsheng Lin <linyunsheng@...wei.com>,
Alex Vesker <valex@...lanox.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 0/3] devlink region trigger support
Mon, Jan 13, 2020 at 07:16:51PM CET, jacob.e.keller@...el.com wrote:
>On 1/13/2020 3:34 AM, Jakub Kicinski wrote:
>> On Mon, 13 Jan 2020 09:39:50 +0800, Yunsheng Lin wrote:
>>> 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.
>>
>
>Right. I'm actually wondering about this as well. Region snapshots are
>captured in whole and stored and then returned through the devlink
>region commands.
Well, driver does not have to support snapshots for particular region,
only live reading. Yes, this needs to be implemented.
>
>This could be problematic if you wanted to expose a larger chunk of
>registers or addressable sections of flash contents, as the size of the
>contents goes beyond a single page.
>
>If we instead focus regions onto the live-read aspect, the API can
>simply be a request to read a segment of the region. Then, the driver
>could perform the read of that chunk and report it back.
Yep.
Powered by blists - more mailing lists