On Fri, 30 Oct 2020 20:06:31 -0400, Douglas Gilbert wrote: > I believe the logic is correct (and scsi_debug doesn't set the INFO field > in its CAW, but should), but I wonder about performance. > > If the probability of equality is high (e.g. like it is usually with > VERIFY(BytChk=1) ) and memcmp() is faster than that for-loop (which > could be optimized), then a better strategy might be to always do memcmp() > first and only if it fails go into the byte by byte for-loop to find the > offset of the first miscompare. While adding the INFO return to tgt I noticed that it had the same memcmp-with-miscompare-for-loop logic that you describe. I'm only aware of ESXi as a COMPARE AND WRITE consumer and I think probability of equality is quite high (@Dirk: perhaps you can confirm?). > IMO this should only be considered, if there is going to be a "v4" of > this patchset. I think this optimization wouldn't make the code much more complex, so I'll do a re-spin with this change. Thanks for the feedback. Cheers, David
