From: Jakub Kicinski <jakub.kicinski@netronome.com> To: Alex Vesker <valex@mellanox.com> Cc: netdev@vger.kernel.org, jiri@mellanox.com, dsahern@gmail.com, andrew@lunn.ch, rahul.lakkireddy@chelsio.com, linux-wireless@vger.kernel.org, Johannes Berg <johannes@sipsolutions.net> Subject: Re: [PATCH net-next v2 00/11] devlink: Add support for region access Date: Wed, 11 Jul 2018 11:48:27 -0700 [thread overview] Message-ID: <20180711114821.1d50ba63@cakuba.lan> (raw) In-Reply-To: <1531305788-29420-1-git-send-email-valex@mellanox.com> CC: linux-wireless, wifi chips used to have similar problem On Wed, 11 Jul 2018 13:42:57 +0300, Alex Vesker wrote: > This is a proposal which will allow access to driver defined address > regions using devlink. Each device can create its supported address > regions and register them. A device which exposes a region will allow > access to it using devlink. > > The suggested implementation will allow exposing regions to the user, > reading and dumping snapshots taken from different regions. > A snapshot represents a memory image of a region taken by the driver. > > If a device collects a snapshot of an address region it can be later > exposed using devlink region read or dump commands. > This functionality allows for future analyses on the snapshots to be > done. > > The major benefit of this support is not only to provide access to > internal address regions which were inaccessible to the user but also > to provide an additional way to debug complex error states using the > region snapshots. > > Implemented commands: > $ devlink region help > $ devlink region show [ DEV/REGION ] > $ devlink region del DEV/REGION snapshot SNAPSHOT_ID > $ devlink region dump DEV/REGION [ snapshot SNAPSHOT_ID ] > $ devlink region read DEV/REGION [ snapshot SNAPSHOT_ID ] > address ADDRESS length length You got me excited with the read without snapshot but then you say below that it's future work :) > Show all of the exposed regions with region sizes: > $ devlink region show > pci/0000:00:05.0/cr-space: size 1048576 snapshot [1 2] > pci/0000:00:05.0/fw-health: size 64 snapshot [1 2] > > Delete a snapshot using: > $ devlink region del pci/0000:00:05.0/cr-space snapshot 1 > > 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 > > For more information you can check devlink-region.8 man page > > Future: > There is a plan to extend the support to include a write command > as well as performing read and dump live region Reading live region would be very interesting and alleviate the need for complicated ethtool dump marshalling a number of drivers started doing (incl. nfp). Any plans on that? Write support I'm less excited about :)
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <jakub.kicinski-wFxRvT7yatFl57MIdRCFDg@public.gmane.org> To: Alex Vesker <valex-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, jiri-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org, dsahern-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, andrew-g2DYL2Zd6BY@public.gmane.org, rahul.lakkireddy-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org, linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> Subject: Re: [PATCH net-next v2 00/11] devlink: Add support for region access Date: Wed, 11 Jul 2018 11:48:27 -0700 [thread overview] Message-ID: <20180711114821.1d50ba63@cakuba.lan> (raw) In-Reply-To: <1531305788-29420-1-git-send-email-valex-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> CC: linux-wireless, wifi chips used to have similar problem On Wed, 11 Jul 2018 13:42:57 +0300, Alex Vesker wrote: > This is a proposal which will allow access to driver defined address > regions using devlink. Each device can create its supported address > regions and register them. A device which exposes a region will allow > access to it using devlink. > > The suggested implementation will allow exposing regions to the user, > reading and dumping snapshots taken from different regions. > A snapshot represents a memory image of a region taken by the driver. > > If a device collects a snapshot of an address region it can be later > exposed using devlink region read or dump commands. > This functionality allows for future analyses on the snapshots to be > done. > > The major benefit of this support is not only to provide access to > internal address regions which were inaccessible to the user but also > to provide an additional way to debug complex error states using the > region snapshots. > > Implemented commands: > $ devlink region help > $ devlink region show [ DEV/REGION ] > $ devlink region del DEV/REGION snapshot SNAPSHOT_ID > $ devlink region dump DEV/REGION [ snapshot SNAPSHOT_ID ] > $ devlink region read DEV/REGION [ snapshot SNAPSHOT_ID ] > address ADDRESS length length You got me excited with the read without snapshot but then you say below that it's future work :) > Show all of the exposed regions with region sizes: > $ devlink region show > pci/0000:00:05.0/cr-space: size 1048576 snapshot [1 2] > pci/0000:00:05.0/fw-health: size 64 snapshot [1 2] > > Delete a snapshot using: > $ devlink region del pci/0000:00:05.0/cr-space snapshot 1 > > 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 > > For more information you can check devlink-region.8 man page > > Future: > There is a plan to extend the support to include a write command > as well as performing read and dump live region Reading live region would be very interesting and alleviate the need for complicated ethtool dump marshalling a number of drivers started doing (incl. nfp). Any plans on that? Write support I'm less excited about :)
next prev parent reply other threads:[~2018-07-11 18:54 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-07-11 10:42 [PATCH net-next v2 00/11] devlink: Add support for region access Alex Vesker 2018-07-11 10:42 ` [PATCH net-next v2 01/11] devlink: Add support for creating and destroying regions Alex Vesker 2018-07-11 10:42 ` [PATCH net-next v2 02/11] devlink: Add callback to query for snapshot id before snapshot create Alex Vesker 2018-07-11 10:43 ` [PATCH net-next v2 03/11] devlink: Add support for creating region snapshots Alex Vesker 2018-07-11 10:43 ` [PATCH net-next v2 04/11] devlink: Add support for region get command Alex Vesker 2018-07-11 18:52 ` Jakub Kicinski 2018-07-11 10:43 ` [PATCH net-next v2 05/11] devlink: Extend the support querying for region snapshot IDs Alex Vesker 2018-07-11 10:43 ` [PATCH net-next v2 06/11] devlink: Add support for region snapshot delete command Alex Vesker 2018-07-11 10:43 ` [PATCH net-next v2 07/11] devlink: Add support for region snapshot read command Alex Vesker 2018-07-11 10:43 ` [PATCH net-next v2 08/11] net/mlx4_core: Add health buffer address capability Alex Vesker 2018-07-11 10:43 ` [PATCH net-next v2 09/11] net/mlx4_core: Add Crdump FW snapshot support Alex Vesker 2018-07-11 10:43 ` [PATCH net-next v2 10/11] devlink: Add generic parameters region_snapshot Alex Vesker 2018-07-11 10:43 ` [PATCH net-next v2 11/11] net/mlx4_core: Use devlink region_snapshot parameter Alex Vesker 2018-07-11 18:48 ` Jakub Kicinski [this message] 2018-07-11 18:48 ` [PATCH net-next v2 00/11] devlink: Add support for region access Jakub Kicinski 2018-07-12 6:21 ` Alex Vesker 2018-08-15 20:25 ` Johannes Berg
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180711114821.1d50ba63@cakuba.lan \ --to=jakub.kicinski@netronome.com \ --cc=andrew@lunn.ch \ --cc=dsahern@gmail.com \ --cc=jiri@mellanox.com \ --cc=johannes@sipsolutions.net \ --cc=linux-wireless@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=rahul.lakkireddy@chelsio.com \ --cc=valex@mellanox.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.