From: Christoph Hellwig <hch@infradead.org>
To: Nitesh Shetty <nj.shetty@samsung.com>
Cc: "Jens Axboe" <axboe@kernel.dk>,
"Jonathan Corbet" <corbet@lwn.net>,
"Alasdair Kergon" <agk@redhat.com>,
"Mike Snitzer" <snitzer@kernel.org>,
dm-devel@redhat.com, "Keith Busch" <kbusch@kernel.org>,
"Christoph Hellwig" <hch@lst.de>,
"Sagi Grimberg" <sagi@grimberg.me>,
"James Smart" <james.smart@broadcom.com>,
"Chaitanya Kulkarni" <kch@nvidia.com>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Christian Brauner" <brauner@kernel.org>,
martin.petersen@oracle.com, linux-scsi@vger.kernel.org,
willy@infradead.org, hare@suse.de, djwong@kernel.org,
bvanassche@acm.org, ming.lei@redhat.com, dlemoal@kernel.org,
nitheshshetty@gmail.com, gost.dev@samsung.com,
"Kanchan Joshi" <joshi.k@samsung.com>,
"Javier González" <javier.gonz@samsung.com>,
"Anuj Gupta" <anuj20.g@samsung.com>,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, linux-nvme@lists.infradead.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v12 5/9] nvme: add copy offload support
Date: Mon, 5 Jun 2023 06:43:41 -0700 [thread overview]
Message-ID: <ZH3mjUb+yqI11XD8@infradead.org> (raw)
In-Reply-To: <20230605121732.28468-6-nj.shetty@samsung.com>
> break;
> case REQ_OP_READ:
> - ret = nvme_setup_rw(ns, req, cmd, nvme_cmd_read);
> + if (unlikely(req->cmd_flags & REQ_COPY))
> + nvme_setup_copy_read(ns, req);
> + else
> + ret = nvme_setup_rw(ns, req, cmd, nvme_cmd_read);
> break;
> case REQ_OP_WRITE:
> - ret = nvme_setup_rw(ns, req, cmd, nvme_cmd_write);
> + if (unlikely(req->cmd_flags & REQ_COPY))
> + ret = nvme_setup_copy_write(ns, req, cmd);
> + else
> + ret = nvme_setup_rw(ns, req, cmd, nvme_cmd_write);
Yikes. Overloading REQ_OP_READ and REQ_OP_WRITE with something entirely
different brings us back the horrors of the block layer 15 years ago.
Don't do that. Please add separate REQ_COPY_IN/OUT (or maybe
SEND/RECEIVE or whatever) methods.
> + /* setting copy limits */
> + if (blk_queue_flag_test_and_set(QUEUE_FLAG_COPY, q))
I don't understand this comment.
> +struct nvme_copy_token {
> + char *subsys;
> + struct nvme_ns *ns;
> + sector_t src_sector;
> + sector_t sectors;
> +};
Why do we need a subsys token? Inter-namespace copy is pretty crazy,
and not really anything we should aim for. But this whole token design
is pretty odd anyway. The only thing we'd need is a sequence number /
idr / etc to find an input and output side match up, as long as we
stick to the proper namespace scope.
> + if (unlikely((req->cmd_flags & REQ_COPY) &&
> + (req_op(req) == REQ_OP_READ))) {
> + blk_mq_start_request(req);
> + return BLK_STS_OK;
> + }
This really needs to be hiden inside of nvme_setup_cmd. And given
that other drivers might need similar handling the best way is probably
to have a new magic BLK_STS_* value for request started but we're
not actually sending it to hardware.
next prev parent reply other threads:[~2023-06-05 13:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20230605122104epcas5p4ef1775cd4a218faa7b2459d58f63c275@epcas5p4.samsung.com>
2023-06-05 12:17 ` [PATCH v12 0/9] Implement copy offload support Nitesh Shetty
[not found] ` <CGME20230605122122epcas5p27d70bd972c1063ecb543ea4489870fd7@epcas5p2.samsung.com>
2023-06-05 12:17 ` [PATCH v12 1/9] block: Introduce queue limits for copy-offload support Nitesh Shetty
[not found] ` <CGME20230605122141epcas5p256df105da840c937758de63e67516f32@epcas5p2.samsung.com>
2023-06-05 12:17 ` [PATCH v12 2/9] block: Add copy offload support infrastructure Nitesh Shetty
[not found] ` <CGME20230605122208epcas5p297068ea23b0aff43e40751219574ff9f@epcas5p2.samsung.com>
2023-06-05 12:17 ` [PATCH v12 3/9] block: add emulation for copy Nitesh Shetty
[not found] ` <CGME20230605122239epcas5p236a716d16fa1d1a2dfff856158deb5af@epcas5p2.samsung.com>
2023-06-05 12:17 ` [PATCH v12 4/9] fs, block: copy_file_range for def_blk_ops for direct block device Nitesh Shetty
[not found] ` <CGME20230605122310epcas5p4aaebfc26fe5377613a36fe50423cf494@epcas5p4.samsung.com>
2023-06-05 12:17 ` [PATCH v12 5/9] nvme: add copy offload support Nitesh Shetty
2023-06-05 13:43 ` Christoph Hellwig [this message]
2023-06-06 11:35 ` Nitesh Shetty
2023-06-07 7:12 ` Christoph Hellwig
2023-06-08 12:08 ` Nitesh Shetty
2023-06-09 4:24 ` Christoph Hellwig
2023-07-10 6:14 ` Nitesh Shetty
2023-06-08 1:36 ` Martin K. Petersen
[not found] ` <CGME20230605122330epcas5p18a452356d5bc39b852b85304bac5b0cc@epcas5p1.samsung.com>
2023-06-05 12:17 ` [PATCH v12 6/9] nvmet: add copy command support for bdev and file ns Nitesh Shetty
[not found] ` <CGME20230605122349epcas5p2de6c758bc38194ebfb1fd8c700e45608@epcas5p2.samsung.com>
2023-06-05 12:17 ` [PATCH v12 7/9] dm: Add support for copy offload Nitesh Shetty
[not found] ` <CGME20230605122402epcas5p2d2fc7493b04aaa70363324429411e689@epcas5p2.samsung.com>
2023-06-05 12:17 ` [PATCH v12 8/9] dm: Enable copy offload for dm-linear target Nitesh Shetty
[not found] ` <CGME20230605122416epcas5p3b37c08a7bf7ad57361b22be0f30d3bf7@epcas5p3.samsung.com>
2023-06-05 12:17 ` [PATCH v12 9/9] null_blk: add support for copy offload Nitesh Shetty
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=ZH3mjUb+yqI11XD8@infradead.org \
--to=hch@infradead.org \
--cc=agk@redhat.com \
--cc=anuj20.g@samsung.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=bvanassche@acm.org \
--cc=corbet@lwn.net \
--cc=djwong@kernel.org \
--cc=dlemoal@kernel.org \
--cc=dm-devel@redhat.com \
--cc=gost.dev@samsung.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=james.smart@broadcom.com \
--cc=javier.gonz@samsung.com \
--cc=joshi.k@samsung.com \
--cc=kbusch@kernel.org \
--cc=kch@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=ming.lei@redhat.com \
--cc=nitheshshetty@gmail.com \
--cc=nj.shetty@samsung.com \
--cc=sagi@grimberg.me \
--cc=snitzer@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).