>>>>> "Sagi" == Sagi Grimberg <sagig@xxxxxxxxxxxxxxxxxx> writes: Sagi> Right, but what do we expect from the LLD to do when prot_op is Sagi> READ_STRIP/WRITE_GENERATE (non-DIX)? I would expect that for Sagi> WRITE_GENERATE the LLD will allocate protection sg-list and Sagi> compute DIF right? And for READ_STRIP I would imagine that the Sagi> LLD will "receive" protection sg-list from the target and "strip" Sagi> it. Now since vhost_scsi/tcm_loop are calling Sagi> target_submit_map_sgls() they emulate both the initiator LLD and Sagi> the target LLD. So perhaps they should provide the target Sagi> protection sg-list for target to do checks and just not pass it to Sagi> scsi_cmnd. what do you think? Depends how pedantically correct we want to be, I guess? When the initiator is also the target things get murky. scsi_debug landed somewhere between DIX and DIF for that reason. The real question is whether there is actually an I/O path to protect? It seems somewhat pointless to generate CRCs and then hand the resulting buffer to a "target" function call that then does a pass to verify it without any real data movement taking place in between. The corruption window in that case is fairly small. >> And on the target end you should only do DIF transfers and checks if >> *PROTECT is set in the CDB. Sagi> So you don't think there is any value in offering target that can Sagi> protect it's stored data against legacy initiators? If the target decides to leverage DIF internally (i.e. to the backing store) that's fine. That's a different SCSI nexus and entirely at the target's discretion. -- 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
