From: minwoo.im.dev@gmail.com (Minwoo Im)
Subject: [RFC PATCH 5/5] nvme-trace: Add tracing for req_comp in target
Date: Sat, 1 Jun 2019 11:37:54 +0900 [thread overview]
Message-ID: <20190601023752.GA3349@minwooim-desktop> (raw)
In-Reply-To: <b2e1e9f4-a96c-9f72-d787-1cd0a6248aa0@grimberg.me>
On 19-05-31 16:29:06, Sagi Grimberg wrote:
>
> > @@ -207,20 +208,50 @@ TRACE_EVENT(nvme_complete_rq,
> > __field(u16, status)
> > ),
> > TP_fast_assign(
> > - __entry->ctrl_id = nvme_req(req)->ctrl->instance;
> > - __entry->qid = nvme_req_qid(req);
> > - __entry->cid = req->tag;
> > - __entry->result = le64_to_cpu(nvme_req(req)->result.u64);
> > - __entry->retries = nvme_req(req)->retries;
> > - __entry->flags = nvme_req(req)->flags;
> > - __entry->status = nvme_req(req)->status;
> > - __assign_disk_name(__entry->disk, req->rq_disk);
> > + set_trace_type(__entry->type, req);
> > + if (__entry->type != NVME_TRACE_TARGET) {
> > + struct request *req = (struct request *) req;
> > +
> > + __entry->ctrl_id = nvme_req(req)->ctrl->instance;
> > + __entry->qid = nvme_req_qid(req);
> > + __entry->cid = req->tag;
> > + __entry->result =
> > + le64_to_cpu(nvme_req(req)->result.u64);
> > + __entry->retries = nvme_req(req)->retries;
> > + __entry->flags = nvme_req(req)->flags;
> > + __entry->status = nvme_req(req)->status;
> > + __assign_disk_name(__entry->disk, req->rq_disk);
> > + } else {
> > + struct nvmet_ctrl *ctrl = nvmet_req_to_ctrl(req);
> > + struct nvmet_cq *cq = ((struct nvmet_req *) req)->cq;
> > + struct nvme_completion *cqe =
> > + ((struct nvmet_req *) req)->cqe;
> > + struct nvmet_ns *ns = ((struct nvmet_req *) req)->ns;
> > +
> > + __entry->ctrl_id = ctrl ? ctrl->cntlid : 0;
> > + __entry->qid = cq->qid;
> > + __entry->cid = cqe->command_id;
> > + __entry->result = cqe->result.u64;
> > + __entry->flags = 0;
> > + __entry->status = cqe->status >> 1;
>
> Why not keep the dnr bit?
Hi Sagi,
Thanks for your review on this. It's just for phase tag which might
not need for us here. Thanks to your review, I have realized that it
should be like:
__entry->status = le16_to_cpu(cqe->status) >> 1;
I will prepare V5 patch series with this.
Thanks,
prev parent reply other threads:[~2019-06-01 2:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-27 17:53 [RFC PATCH V4 0/5] nvme-trace: Add support for fabrics command Minwoo Im
2019-05-27 17:53 ` [RFC PATCH 1/5] nvme: Make trace common for host and target both Minwoo Im
2019-05-30 1:09 ` Sagi Grimberg
2019-05-27 17:53 ` [RFC PATCH 2/5] nvme-trace: Support tracing fabrics commands from host-side Minwoo Im
2019-05-30 1:13 ` Sagi Grimberg
2019-05-27 17:53 ` [RFC PATCH 3/5] nvme: Introduce nvme_is_fabrics to check fabrics cmd Minwoo Im
2019-05-30 1:13 ` Sagi Grimberg
2019-05-27 17:53 ` [RFC PATCH 4/5] nvme-trace: Add tracing for req_init in target Minwoo Im
2019-05-27 17:53 ` [RFC PATCH 5/5] nvme-trace: Add tracing for req_comp " Minwoo Im
2019-05-31 23:29 ` Sagi Grimberg
2019-06-01 2:37 ` Minwoo Im [this message]
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=20190601023752.GA3349@minwooim-desktop \
--to=minwoo.im.dev@gmail.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox