On Sat, 2014-01-18 at 13:42 -0800, Roland Dreier wrote: > On Thu, Jan 16, 2014 at 1:14 PM, Nicholas A. Bellinger > <nab@xxxxxxxxxxxxxxx> wrote: > > I've reviewed the API from the perspective of what's required for > > implementing protection support in iser, and currently don't have any > > recommendations or objections beyond what has been proposed by Sagi & Co > > in PATCH-v4 code. > > I guess I'm a little confused about why we need verbs support for this > to implement DIF/DIX in iser. Isn't the whole point of protection to > have end-to-end checksums, rather than having checksums computed by > the transport after there's a chance for corruption? > So to my knowledge, there are three target side DIX HBA modes of operation: - TARGET PASS: Fabric + Backend support PI - TARGET INSERT: Fabric does not support PI, backend supports PI - TARGET STRIP: Fabric supports PI, backend does not support PI The scenario your thinking about above is the 'TARGET INSERT' case, where the initiator does not generate PI, but the backend device on the target side expects PI, so the target fabric ends up generating PI on incoming WRITEs, and verifying + striping PI on outgoing READs. The scenario for 'TARGET STRIP' is when the initiator generates PI but the backend device does not support/process PI, so the target verifies + strips PI on incoming WRITESs, and inserts PI on outgoing READs. Your correct that both of these modes don't provide true end-to-end protection, and my understanding is that they are provided as a way to accommodate existing fabrics + backend devices where PI is not supported all the way through the stack. The 'TARGET PASS' is the scenario that provides true end-to-end guarantees, where for WRITEs PI is generated by the Host OS, verified + passed on the initiator side HBA, verified + passed on the target HBA, and verified + stored on the device backend. For READs, PI is retrieved from the backend device, verified + passed on the target HBA, verified + passed on the initiator HBA, and finally verified on the Host OS. So in the proposed RDMA VERBs changes these three modes of target DIX operation are supported. Also it's my understanding (Sagi & Co, please correct me), that the proposed changes are implemented to be independent of target/initiator mode DIX operation. --nab -- 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
