All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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: 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.