[PATCH] nvme: trace: parse format nvm command in detail

[Dan Williams]

On Fri, Jan 8, 2021 at 2:34 PM Keith Busch <kbusch at kernel.org> wrote:
>
> On Wed, Jan 06, 2021 at 10:00:53AM +0100, Christoph Hellwig wrote:
> > On Mon, Jan 04, 2021 at 08:02:20AM -0800, Keith Busch wrote:
> > > Perhaps it's too late since we've already gone done this path in the
> > > driver, but IMO, we should have only traced raw dwords without any
> > > additional decoding. This would have allowed consistent output for all
> > > kernel versions and resilient to future spec changes. Then that could
> > > have made possible for a user space utility to do the decoding to a
> > > human friendly format, kind of like what blkparse does for block layer
> > > trace events.
> >
> > the block tracepoints actually contain pretty detailed decoding as well.
>
> Sure, but what I'm trying to say is that the current nvme decoding isn't
> forward compatible with spec changes that tools will be able to use, and
> will not be possible to see currently reserved fields. It will be a
> never ending maintenance burden to chase those changes, and there will
> be no consistency in nvme trace events for different kernel versions.
>
> If it would help at all to move in a more future proof direction, I
> wrote a little script handling all the decoding and posted it here:
>
>   https://github.com/linux-nvme/nvme-trace/blob/main/nvme-trace.pl
>
> If that's okay, we can greatly simplify the nvme tracing so that it
> will always be consistent and able to obtain new command fields as they
> show up.

Is there a more centralized place to land such a helper? trace-cmd,
perf? The nice thing about kernel parsing is I don't need to have a
separate pile of disparate tools across subsystems.