Re: [PATCH 6/6] [SCSI] sd: Implement copy offload support

[Douglas Gilbert <dgilbert@interlog.com>]

On 14-05-28 11:52 PM, Martin K. Petersen wrote:
> Implement support for hardware copy offload. This initial implementation
> only supports EXTENDED COPY(LID1). If need be we can add support for
> LID4 or token copy at a later date.
>
> If a device has the 3PC flag set in the standard INQUIRY response we'll
> issue a RECEIVE COPY OPERATION PARAMETERS command. We require the device
> to support two copy source/copy destination descriptors and one block to
> block (0x02) segment descriptor. The device must support the NAA
> identification descriptor (0xE4). If the device is capable we'll set the
> queue limits to indicate that the device supports copy offload.

SPC-4 has downgraded the RECEIVE COPY OPERATION PARAMETERS command
in favour of the new Third Party Copy (TPC) VPD page [0x8f]. If the
latter is present, it should be used. Most real world implementations
of XCOPY(LID1) comply (loosely) with SPC-2 and SPC-3 since VMWare's
VAAI is the effective "standard".

Further I noticed some ODX ** implementations which do use that TPC
VPD page, do not implement its (SPC-4 defined) mandatory descriptors
(0x1 and 0x8001) needed to support XCOPY(LID1). Perhaps there may be
some convergence after SPC-4 becomes a standard.

In any case, this patch set looks good.

May I also point out the NAB's target subsystem has a block to
block XCOPY(LID1) implementation. So it can be used to test
this patch set. The standards require copies between LUs in
the same target to be supported (if xcopy is supported),
otherwise support is optional (i.e. between LUs in different
targets). Hence most implementations restrict the LUs to being
in the same target.

Doug Gilbert


** ODX is MS's name for the subset of XCOPY(LID4) defined in
    SBC-3 using the POPULATE TOKEN and WRITE USING TOKEN
    commands. So this is a "token copy" referred to above.