Re: [PATCH 0/9] target: Add support for EXTENDED_COPY (VAAI) offload emulation

[Douglas Gilbert <dgilbert@interlog.com>]

On 13-08-23 02:33 PM, Martin K. Petersen wrote:
>>>>>> "Doug" == Douglas Gilbert <dgilbert@interlog.com> writes:
>
> Doug> The SCSI opcodes associated with it (0x83 and 0x84) have been
> Doug> renamed THIRD PARTY COPY OUT and IN, and
>
> Where did you see that? My SPC still has EXTENDED COPY.

SCSI _opcodes_ == SCSI operation codes. In other words the
name associated with all service actions (commands) that have
as their first byte 0x83 and 0x84 .

spc4r36h.pdf Annex F.3.1 and changed in spc4r34. Yes, well
hidden but IMO useful. So now we can use the term "Third party
copy" to cover:
   - EXTENDED COPY(LID1) and associated commands
     also found in SPC-2 and SPC-3 (with the "LID1" suffix)
   - EXTENDED COPY(LID4) and associated commands
   - the XCOPY LITE commands: POPULATE TOKEN and WRITE USING TOKEN

> Doug> Confused? I certainly was.
>
> Yeah, this is UNMAP all over again, just 100 times worse :(

Well what EXTENDED COPY (offload copy) is trying to do
ain't simple but obviously there could be a substantial
performance pay-off.

There is a "Third-party copy implementation and usage" Annex
(D) in spc4r36h.pdf . It could do with some more explanatory
text.

> Anyway. Excited to see nab posting the patches! My copy offload code
> from the spring has been getting stale both in the T10 and the kernel
> sense. But at least we know what I'll be working on next week :)

BTW I have ported the sg_xcopy "LID1" xcopy logic into
my ddpt utility. That gives two advantages:
   - can cope with ibs!=obs
   - runs on OSes other than Linux

Doug Gilbert