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

[Keith Busch]

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.