From: Chaitanya Kulkarni <chaitanyak@nvidia.com> To: "dgilbert@interlog.com" <dgilbert@interlog.com> Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>, "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>, "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>, "target-devel@vger.kernel.org" <target-devel@vger.kernel.org>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>, "dm-devel@redhat.com" <dm-devel@redhat.com>, "linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org> Subject: Re: [RFC PATCH 0/8] block: add support for REQ_OP_VERIFY Date: Thu, 11 Nov 2021 08:27:59 +0000 [thread overview] Message-ID: <d862ddb6-4c58-e046-ab6f-98cf314fec5d@nvidia.com> (raw) In-Reply-To: <7f734d14-c107-daa3-aaa8-0eda3c592add@interlog.com> >> Please note that the interfaces for blk-lib.c REQ_OP_VERIFY emulation >> will change in future I put together for the scope of RFC. >> >> Any comments are welcome. > > Hi, > You may also want to consider higher level support for the NVME COMPARE > and SCSI VERIFY(BYTCHK=1) commands. Since PCIe and SAS transports are > full duplex, replacing two READs (plus a memcmp in host memory) with > one READ and one COMPARE may be a win on a bandwidth constrained > system. It is a safe to assume the data-in transfers on a storage transport > exceed (probably by a significant margin) the data-out transfers. An > offloaded COMPARE switches one of those data-in transfers to a data-out > transfer, so it should improve the bandwidth utilizatio > I've thought about adding a support for the compare and friends. But those commands are optional (correct me if I'm wrong) and I couldn't find right usecase(s) to justify the kernel plubming. Do you happened to have usecases or application which are using compare command extensively or perhaps we point to an application your dd modified version ? > I did some brief benchmarking on a NVME SSD's COMPARE command (its > optional) > and the results were underwhelming. OTOH using my own dd variants (which > can do compare instead of copy) and a scsi_debug target (i.e. RAM) I have > seen compare times of > 15 GBps while a copy rarely exceeds 9 GBps. > This is what I'd expect when it comes to performance, but we need a strong usecase with in-kernel user to support that, I'd be happy to add that support. > > BTW The SCSI VERIFY(BYTCHK=3) command compares one block sent from > the host with a sequence of logical blocks on the media. So, for example, > it would be a quick way of checking that a sequence of blocks contained > zero-ed data. > I see thanks for the comments and sharing compare related experience, I've thought about that when I worked on REQ_OP_WRITE_ZEROES support :). > Doug Gilbert
WARNING: multiple messages have this Message-ID (diff)
From: Chaitanya Kulkarni <chaitanyak@nvidia.com> To: "dgilbert@interlog.com" <dgilbert@interlog.com> Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>, "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>, "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>, "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>, "dm-devel@redhat.com" <dm-devel@redhat.com>, "target-devel@vger.kernel.org" <target-devel@vger.kernel.org>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, "linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org> Subject: Re: [dm-devel] [RFC PATCH 0/8] block: add support for REQ_OP_VERIFY Date: Thu, 11 Nov 2021 08:27:59 +0000 [thread overview] Message-ID: <d862ddb6-4c58-e046-ab6f-98cf314fec5d@nvidia.com> (raw) In-Reply-To: <7f734d14-c107-daa3-aaa8-0eda3c592add@interlog.com> >> Please note that the interfaces for blk-lib.c REQ_OP_VERIFY emulation >> will change in future I put together for the scope of RFC. >> >> Any comments are welcome. > > Hi, > You may also want to consider higher level support for the NVME COMPARE > and SCSI VERIFY(BYTCHK=1) commands. Since PCIe and SAS transports are > full duplex, replacing two READs (plus a memcmp in host memory) with > one READ and one COMPARE may be a win on a bandwidth constrained > system. It is a safe to assume the data-in transfers on a storage transport > exceed (probably by a significant margin) the data-out transfers. An > offloaded COMPARE switches one of those data-in transfers to a data-out > transfer, so it should improve the bandwidth utilizatio > I've thought about adding a support for the compare and friends. But those commands are optional (correct me if I'm wrong) and I couldn't find right usecase(s) to justify the kernel plubming. Do you happened to have usecases or application which are using compare command extensively or perhaps we point to an application your dd modified version ? > I did some brief benchmarking on a NVME SSD's COMPARE command (its > optional) > and the results were underwhelming. OTOH using my own dd variants (which > can do compare instead of copy) and a scsi_debug target (i.e. RAM) I have > seen compare times of > 15 GBps while a copy rarely exceeds 9 GBps. > This is what I'd expect when it comes to performance, but we need a strong usecase with in-kernel user to support that, I'd be happy to add that support. > > BTW The SCSI VERIFY(BYTCHK=3) command compares one block sent from > the host with a sequence of logical blocks on the media. So, for example, > it would be a quick way of checking that a sequence of blocks contained > zero-ed data. > I see thanks for the comments and sharing compare related experience, I've thought about that when I worked on REQ_OP_WRITE_ZEROES support :). > Doug Gilbert -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2021-11-11 8:28 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-04 6:46 [RFC PATCH 0/8] block: add support for REQ_OP_VERIFY Chaitanya Kulkarni 2021-11-04 6:46 ` [dm-devel] " Chaitanya Kulkarni 2021-11-04 6:46 ` [RFC PATCH 1/8] " Chaitanya Kulkarni 2021-11-04 6:46 ` [dm-devel] " Chaitanya Kulkarni 2021-11-04 17:25 ` Darrick J. Wong 2021-11-04 17:25 ` [dm-devel] " Darrick J. Wong 2021-11-11 8:01 ` Chaitanya Kulkarni 2021-11-11 8:01 ` [dm-devel] " Chaitanya Kulkarni 2021-11-04 6:46 ` [RFC PATCH 2/8] scsi: add REQ_OP_VERIFY support Chaitanya Kulkarni 2021-11-04 6:46 ` [dm-devel] " Chaitanya Kulkarni 2021-11-04 12:33 ` Damien Le Moal 2021-11-04 12:33 ` [dm-devel] " Damien Le Moal 2021-11-11 8:07 ` Chaitanya Kulkarni 2021-11-11 8:07 ` [dm-devel] " Chaitanya Kulkarni 2021-11-04 6:46 ` [RFC PATCH 3/8] nvme: add support for the Verify command Chaitanya Kulkarni 2021-11-04 6:46 ` [dm-devel] " Chaitanya Kulkarni 2021-11-04 22:44 ` Keith Busch 2021-11-04 22:44 ` [dm-devel] " Keith Busch 2021-11-11 8:09 ` Chaitanya Kulkarni 2021-11-11 8:09 ` [dm-devel] " Chaitanya Kulkarni 2021-11-04 6:46 ` [PATCH 4/8] nvmet: add Verify command support for bdev-ns Chaitanya Kulkarni 2021-11-04 6:46 ` [dm-devel] " Chaitanya Kulkarni 2021-11-04 6:46 ` [RFC PATCH 5/8] nvmet: add Verify emulation " Chaitanya Kulkarni 2021-11-04 6:46 ` [dm-devel] " Chaitanya Kulkarni 2021-11-04 6:46 ` [RFC PATCH 6/8] nvmet: add verify emulation support for file-ns Chaitanya Kulkarni 2021-11-04 6:46 ` [dm-devel] " Chaitanya Kulkarni 2021-11-04 6:46 ` [RFC PATCH 7/8] null_blk: add REQ_OP_VERIFY support Chaitanya Kulkarni 2021-11-04 6:46 ` [dm-devel] " Chaitanya Kulkarni 2021-11-04 6:46 ` [RFC PATCH 8/8] md: add support for REQ_OP_VERIFY Chaitanya Kulkarni 2021-11-04 6:46 ` [dm-devel] " Chaitanya Kulkarni 2021-11-11 8:13 ` Chaitanya Kulkarni 2021-11-11 8:13 ` [dm-devel] " Chaitanya Kulkarni 2021-11-12 15:19 ` Mike Snitzer 2021-11-12 15:19 ` [dm-devel] " Mike Snitzer 2021-11-04 7:14 ` [RFC PATCH 0/8] block: " Christoph Hellwig 2021-11-04 7:14 ` [dm-devel] " Christoph Hellwig 2021-11-04 9:27 ` Chaitanya Kulkarni 2021-11-04 9:27 ` [dm-devel] " Chaitanya Kulkarni 2021-11-04 17:32 ` Darrick J. Wong 2021-11-04 17:32 ` [dm-devel] " Darrick J. Wong 2021-11-04 17:34 ` Christoph Hellwig 2021-11-04 17:34 ` [dm-devel] " Christoph Hellwig 2021-11-04 22:37 ` Keith Busch 2021-11-04 22:37 ` [dm-devel] " Keith Busch 2021-11-05 8:25 ` javier 2021-11-05 8:25 ` [dm-devel] " javier 2021-11-11 8:18 ` Chaitanya Kulkarni 2021-11-11 8:18 ` [dm-devel] " Chaitanya Kulkarni 2021-11-04 15:16 ` Douglas Gilbert 2021-11-04 15:16 ` [dm-devel] " Douglas Gilbert 2021-11-11 8:27 ` Chaitanya Kulkarni [this message] 2021-11-11 8:27 ` Chaitanya Kulkarni
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=d862ddb6-4c58-e046-ab6f-98cf314fec5d@nvidia.com \ --to=chaitanyak@nvidia.com \ --cc=dgilbert@interlog.com \ --cc=dm-devel@redhat.com \ --cc=linux-block@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-nvme@lists.infradead.org \ --cc=linux-raid@vger.kernel.org \ --cc=linux-scsi@vger.kernel.org \ --cc=linux-xfs@vger.kernel.org \ --cc=target-devel@vger.kernel.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: linkBe 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.