All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Disseldorp <ddiss@suse.de>
To: Douglas Gilbert <dgilbert@interlog.com>
Cc: target-devel@vger.kernel.org, linux-scsi@vger.kernel.org,
	Mike Christie <michael.christie@oracle.com>,
	"Dirk Hohndel (VMware)" <dirk@hohndel.org>
Subject: Re: [PATCH v3 4/4] scsi: target: return COMPARE AND WRITE miscompare offsets
Date: Sat, 31 Oct 2020 11:38:52 +0100	[thread overview]
Message-ID: <20201031113852.39110f4c@suse.de> (raw)
In-Reply-To: <e475cbf3-6dc8-901f-b5e3-30228e9a03a4@interlog.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: David Disseldorp <ddiss@suse.de>
To: Douglas Gilbert <dgilbert@interlog.com>
Cc: target-devel@vger.kernel.org, linux-scsi@vger.kernel.org,
	Mike Christie <michael.christie@oracle.com>,
	"Dirk Hohndel (VMware)" <dirk@hohndel.org>
Subject: Re: [PATCH v3 4/4] scsi: target: return COMPARE AND WRITE miscompare offsets
Date: Sat, 31 Oct 2020 10:38:52 +0000	[thread overview]
Message-ID: <20201031113852.39110f4c@suse.de> (raw)
In-Reply-To: <e475cbf3-6dc8-901f-b5e3-30228e9a03a4@interlog.com>

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

  reply	other threads:[~2020-10-31 10:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-30 21:39 [PATCH v2 0/4] scsi: target: COMPARE AND WRITE miscompare sense David Disseldorp
2020-10-30 21:39 ` David Disseldorp
2020-10-30 21:39 ` [PATCH v3 1/4] scsi: target: rename struct sense_info to sense_detail David Disseldorp
2020-10-30 21:39   ` David Disseldorp
2020-10-30 21:39 ` [PATCH v3 2/4] scsi: target: rename cmd.bad_sector to cmd.sense_info David Disseldorp
2020-10-30 21:39   ` David Disseldorp
2020-10-30 21:39 ` [PATCH v3 3/4] scsi: target: split out COMPARE AND WRITE memcmp into helper David Disseldorp
2020-10-30 21:39   ` David Disseldorp
2020-10-30 21:39 ` [PATCH v3 4/4] scsi: target: return COMPARE AND WRITE miscompare offsets David Disseldorp
2020-10-30 21:39   ` David Disseldorp
2020-10-31  0:06   ` Douglas Gilbert
2020-10-31  0:06     ` Douglas Gilbert
2020-10-31 10:38     ` David Disseldorp [this message]
2020-10-31 10:38       ` David Disseldorp

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=20201031113852.39110f4c@suse.de \
    --to=ddiss@suse.de \
    --cc=dgilbert@interlog.com \
    --cc=dirk@hohndel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michael.christie@oracle.com \
    --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.