Re: linux rdma 3.14 merge plans

Nicholas A. Bellinger
2014-01-19T03:42:29Z

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@linux-iscsi.org> 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