All of lore.kernel.org
 help / color / mirror / Atom feed
From: hch@lst.de (Christoph Hellwig)
Subject: [PATCH v4 1/2] nvme: add tracepoint for nvme_setup_cmd
Date: Mon, 22 Jan 2018 16:23:01 +0100	[thread overview]
Message-ID: <20180122152301.GA5818@lst.de> (raw)
In-Reply-To: <20180119141819.11938-2-jthumshirn@suse.de>

On Fri, Jan 19, 2018@03:18:18PM +0100, Johannes Thumshirn wrote:
> Signed-off-by: Johannes Thumshirn <jthumshirn at suse.de>
> Reviewed-by: Hannes Reinecke <hare at suse.de>
> Reviewed-by: Martin K. Petersen <martin.petersen at oracle.com>
> Reviewed-by: Keith Busch <keith.busch at intel.com>

This could really use a changelog explaining what you're tracing,
and most importantly why.

> +struct rw_cmd {
> +	__le64 slba;
> +	__le16 length;
> +	__le16 control;
> +	__le32 dsmgmt;
> +	__le32 reftag;
> +	__le16 apptag;
> +	__le16 appmask;
> +};
> +
> +struct dsm_cmd {
> +	__le32 nr;
> +	__le32 attributes;
> +	__u32 rsvd12[4];
> +};

Why do we need all these different defintions?  Just use
cdw2/3/10/11/12/13 for the fields and decode those __le32 on
a per-command basis where needed.

> +const char *nvme_trace_parse_cmd(struct trace_seq *p, bool admin,
> +				 u8 opcode, __le32 *cdw10)
> +{
> +	if (admin) {
> +		switch (opcode) {
> +		case nvme_admin_create_sq:
> +			return nvme_trace_create_sq(p, cdw10);
> +		case nvme_admin_create_cq:
> +			return nvme_trace_create_cq(p, cdw10);
> +		case nvme_admin_identify:
> +			return nvme_trace_admin_identify(p, cdw10);
> +		default:
> +			return nvme_trace_common(p, cdw10);
> +		}
> +	} else {
> +		switch (opcode) {
> +		case nvme_cmd_read:
> +		case nvme_cmd_write:
> +		case nvme_cmd_write_zeroes:
> +			return nvme_trace_read_write(p, cdw10);
> +		case nvme_cmd_dsm:
> +			return nvme_trace_dsm(p, cdw10);
> +		default:
> +			return nvme_trace_common(p, cdw10);
> +		}
> +	}
> +}

Wouldn't it be easier to have separate tracepoints for admin vs
I/O commands?  Especially as people might often want to trace
only one or the other.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Johannes Thumshirn <jthumshirn@suse.de>
Cc: Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
	Keith Busch <keith.busch@intel.com>,
	Linux Kernel Mailinglist <linux-kernel@vger.kernel.org>,
	Hannes Reinecke <hare@suse.de>,
	Linux NVMe Mailinglist <linux-nvme@lists.infradead.org>,
	"Martin K . Petersen" <martin.petersen@oracle.com>
Subject: Re: [PATCH v4 1/2] nvme: add tracepoint for nvme_setup_cmd
Date: Mon, 22 Jan 2018 16:23:01 +0100	[thread overview]
Message-ID: <20180122152301.GA5818@lst.de> (raw)
In-Reply-To: <20180119141819.11938-2-jthumshirn@suse.de>

On Fri, Jan 19, 2018 at 03:18:18PM +0100, Johannes Thumshirn wrote:
> Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
> Reviewed-by: Hannes Reinecke <hare@suse.de>
> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
> Reviewed-by: Keith Busch <keith.busch@intel.com>

This could really use a changelog explaining what you're tracing,
and most importantly why.

> +struct rw_cmd {
> +	__le64 slba;
> +	__le16 length;
> +	__le16 control;
> +	__le32 dsmgmt;
> +	__le32 reftag;
> +	__le16 apptag;
> +	__le16 appmask;
> +};
> +
> +struct dsm_cmd {
> +	__le32 nr;
> +	__le32 attributes;
> +	__u32 rsvd12[4];
> +};

Why do we need all these different defintions?  Just use
cdw2/3/10/11/12/13 for the fields and decode those __le32 on
a per-command basis where needed.

> +const char *nvme_trace_parse_cmd(struct trace_seq *p, bool admin,
> +				 u8 opcode, __le32 *cdw10)
> +{
> +	if (admin) {
> +		switch (opcode) {
> +		case nvme_admin_create_sq:
> +			return nvme_trace_create_sq(p, cdw10);
> +		case nvme_admin_create_cq:
> +			return nvme_trace_create_cq(p, cdw10);
> +		case nvme_admin_identify:
> +			return nvme_trace_admin_identify(p, cdw10);
> +		default:
> +			return nvme_trace_common(p, cdw10);
> +		}
> +	} else {
> +		switch (opcode) {
> +		case nvme_cmd_read:
> +		case nvme_cmd_write:
> +		case nvme_cmd_write_zeroes:
> +			return nvme_trace_read_write(p, cdw10);
> +		case nvme_cmd_dsm:
> +			return nvme_trace_dsm(p, cdw10);
> +		default:
> +			return nvme_trace_common(p, cdw10);
> +		}
> +	}
> +}

Wouldn't it be easier to have separate tracepoints for admin vs
I/O commands?  Especially as people might often want to trace
only one or the other.

  reply	other threads:[~2018-01-22 15:23 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-19 14:18 [PATCH v4 0/2] add tracepoints for nvme command submission and completion Johannes Thumshirn
2018-01-19 14:18 ` Johannes Thumshirn
2018-01-19 14:18 ` [PATCH v4 1/2] nvme: add tracepoint for nvme_setup_cmd Johannes Thumshirn
2018-01-19 14:18   ` Johannes Thumshirn
2018-01-22 15:23   ` Christoph Hellwig [this message]
2018-01-22 15:23     ` Christoph Hellwig
2018-01-22 15:53     ` Johannes Thumshirn
2018-01-22 15:53       ` Johannes Thumshirn
2018-01-22 15:59       ` Christoph Hellwig
2018-01-22 15:59         ` Christoph Hellwig
2018-01-22 16:04         ` Johannes Thumshirn
2018-01-22 16:04           ` Johannes Thumshirn
2018-01-22 16:10           ` Christoph Hellwig
2018-01-22 16:10             ` Christoph Hellwig
2018-01-22 16:15             ` Johannes Thumshirn
2018-01-22 16:15               ` Johannes Thumshirn
2018-01-19 14:18 ` [PATCH v4 2/2] nvme: add tracepoint for nvme_complete_rq Johannes Thumshirn
2018-01-19 14:18   ` Johannes Thumshirn
2018-01-22 15:23   ` Christoph Hellwig
2018-01-22 15:23     ` Christoph Hellwig
2018-01-22 15:30     ` Johannes Thumshirn
2018-01-22 15:30       ` Johannes Thumshirn
2018-01-22 19:35       ` Martin K. Petersen
2018-01-22 19:35         ` Martin K. Petersen

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=20180122152301.GA5818@lst.de \
    --to=hch@lst.de \
    /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: link
Be 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.