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