>>>>> "Sagi" == Sagi Grimberg <sagig@xxxxxxxxxxxxxxxxxx> writes: >> AFAICT for the two READ_10s that come down with prot_op == >> READ_STRIP, there is no associated scsi_prot_sglist() or >> scsi_prot_sg_count(), so from vhost-scsi's perspective, the virtio >> header will signal no protection SGLs are available, and that the >> operation should function like a normal unprotected operation. Sagi> In my opinion that is a miss-interpretation. READ_STRIP means Sagi> "validate protection and strip it". Is WRITE_GENERATE also a Sagi> normal unprotected operation? In the WRITE_INSERT case the target is doing the checking. Sagi> As MKP said, it's a matter of how pedantic we want to be. we can Sagi> just say that for vhost_scsi/loopback LLDs there is no real Sagi> justification of doing these operations, but the meaning is that Sagi> we are performing a violation. Probably a minor one, but still a Sagi> violation. I still don't get the violation thing. For the kernel to issue any command with a prot_op > 0, both initiator and target need to signal support for the relevant DIF type. The SCSI midlayer is not going to issue a READ_STRIP or WRITE_INSERT unless both initiator and target support DIF. This has nothing to do with whether automatic protection is enabled in the block layer (which is really a DIX thing and technically only covers communication between block layer and HBA). - If the block layer sends you a command with no prot sgl, and both initiator and target support DIF Type N, then you'll see READ_STRIP or WRITE_INSERT. - If the block layer sends you a command with a prot sgl (which means the initiator supports DIX Type N), and initiator and target support DIF Type N, then you'll see READ_PASS / WRITE_PASS. - If the block layer sends you a command with a prot sgl (which means the initiator supports DIX Type N), and the initiator and/or targer do not support DIF Type N, then you'll see READ_INSERT or WRITE_STRIP. You should never ignore the prot_op. But it is important to report the initiator driver's prot_caps and the target's p_type correctly. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
