Re: [PATCH 9/13] mpt2sas: T10 DIF Support - EEDP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "Eric" == Eric Moore <eric.moore@xxxxxxx> writes:

Eric,

+_scsih_setup_eedp(struct scsi_cmnd *scmd, Mpi2SCSIIORequest_t *mpi_request)
[...]
+	/*
+	 * enable ref/app/guard checking
+	 * auto increment ref tag
+	 */
+	mpi_request->EEDPFlags = eedp_flags |
+	    MPI2_SCSIIO_EEDPFLAGS_INC_PRI_REFTAG |
+	    MPI2_SCSIIO_EEDPFLAGS_CHECK_REFTAG |
+	    MPI2_SCSIIO_EEDPFLAGS_CHECK_APPTAG |
+	    MPI2_SCSIIO_EEDPFLAGS_CHECK_GUARD;

How can you check the app tag?


+_scsih_eedp_error_handling(struct scsi_cmnd *scmd, u16 ioc_status)
[...]
+	if (scmd->sc_data_direction == DMA_TO_DEVICE) {
+		sk = ILLEGAL_REQUEST;
+		host_byte = DID_ABORT;
+	} else {
+		sk = ABORTED_COMMAND;
+		host_byte = DID_OK;
+	}

ILLEGAL REQUEST is used when the HBA detects a mismatch between data and
protection information.  If you are not receiving PI from the OS (WRITE
INSERT) then the HBA can't detect an integrity error.  So in the
DMA_TO_DEVICE case only the target can catch the error (and it will
return ABORTED_COMMAND).

For READ, both the drive firmware and the HBA can ostensibly check that
the data buffers and PI match.

Are your EEDP error flags only set when the HBA firmware detects a
problem or also when the drive returns ABORTED COMMAND/0x10?

I.e. do we get double failure scenarios (both drive and HBA detect the
mismatch)?


+	scsi_host_set_prot(shost, SHOST_DIF_TYPE1_PROTECTION
+	    | SHOST_DIF_TYPE3_PROTECTION);

How do you handle Type 3?  The application tag and reference tags are
both defined as being opaque storage for Type 3.

If I understand correctly, your firmware only deals with the Type 2
usage model of the application tag.  And Type 1 + 2 usage of the
reference tag.


+	scsi_host_set_guard(shost, SHOST_DIX_GUARD_CRC);

Technically speaking that is only required for DIX exchange.  But
setting it doesn't hurt.

-- 
Martin K. Petersen	Oracle Linux Engineering

--
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux