I have some trouble parsing you English/Question. I think the intent of SCSI PI was that wherever the PI exist it should be checked end-to-end and it may be checked in between. A storage client (server) will have the PI appended in the memory when writing and reading and checking it. As the values are standardized storage may also check it both when reading and when writing but it should not change it. If by implicit you mean inclusive I assume iSCSI Expected data transfer length will take whatever is in the cdb. Block transfer devices will likely add the PI length to the pure data length - i.e. inclusive. iSER may allow placing PI in diferent memory areas than the pure data but I think it has already provisions for that.
Regards, Julo > On May 25, 2014, at 18:30, Sagi Grimberg <[email protected]> wrote: > > Hey All, > > Recently, iSER end-to-end T10-PI support maid it mainline. > I am wandering about the impact T10-PI should or shouldn't have on iSCSI > header > field "Expected Data Transfer Length". > > RFC-7143 states: > "the Expected Data Transfer Length field contains the number of bytes of data > involved in this SCSI operation." > Since this field relates to *data bytes* I kept T10-PI implicit wrt this > field. The iSCSI target calculates the > total transfer length (data + protection) from the cdb transfer length field > and protect bits. > > In FC, the fc_dl field was updated to relate to the total number of transfer > bytes and includes > data and protection bytes. virtio_scsi was added with a header PI section > (virtio_scsi_cmd_req_pi). > > So my question is, should this field be updated to explicitly include T10-PI > bytes like the FC equivalent fc_dl? > Or should T10-PI bytes be implicit? > > I want to pin down this one to avoid a situation where the standard is open > for interpretations. > > Thanks, > Sagi. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
