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. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
