[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180329195154.GB15565@lunn.ch>
Date: Thu, 29 Mar 2018 21:51:54 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Alex Vesker <valex@...lanox.com>
Cc: "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
Tariq Toukan <tariqt@...lanox.com>,
Jiri Pirko <jiri@...lanox.com>
Subject: Re: [PATCH net-next 0/9] devlink: Add support for region access
> >>Show all of the exposed regions with region sizes:
> >>$ devlink region show
> >>pci/0000:00:05.0/cr-space: size 1048576 snapshot [1 2]
> >So you have 2Mbytes of snapshot data. Is this held in the device, or
> >kernel memory?
> This is allocated in devlink, the maximum number of snapshots is set by the
> driver.
And it seems to want contiguous pages. How well does that work after
the system has been running for a while and memory is fragmented?
> >>Dump a snapshot:
> >>$ devlink region dump pci/0000:00:05.0/fw-health snapshot 1
> >>0000000000000000 0014 95dc 0014 9514 0035 1670 0034 db30
> >>0000000000000010 0000 0000 ffff ff04 0029 8c00 0028 8cc8
> >>0000000000000020 0016 0bb8 0016 1720 0000 0000 c00f 3ffc
> >>0000000000000030 bada cce5 bada cce5 bada cce5 bada cce5
> >>
> >>Read a specific part of a snapshot:
> >>$ devlink region read pci/0000:00:05.0/fw-health snapshot 1 address 0
> >> length 16
> >>0000000000000000 0014 95dc 0014 9514 0035 1670 0034 db30
> >Why a separate command? It seems to be just a subset of dump.
>
> This is useful when debugging values on specific addresses, this also
> brings the API one step closer for a read and write API.
The functionality is useful, yes. But why two commands? Why not one
command, dump, which takes optional parameters?
Also, i doubt write support will be accepted. That sounds like the
start of an API to allow a user space driver.
Andrew
Powered by blists - more mailing lists