[ofa-general] Re: [Ips] Calculating the VA in iSER header

[Pete Wyckoff]

dorfman.eli at gmail.com wrote on Thu, 01 May 2008 16:50 +0300:
> InitialR2T=Yes means that R2T is required, hence no unsolicited data.
> Only is both sides, initiator and target agree on InitialR2T=No then
> first data burst is unsolicited.

Thanks for the explanation.  I keep getting that backwards.

> On Tue, Apr 29, 2008 at 8:05 PM, Pete Wyckoff <pw at osc.edu> wrote:
> >  But you missed the impact of immediate data.  We run with the
> >  defaults (I think) that say the first write request packet should be
> >  filled with a bit of the coming data stream.  From iscsid.conf:
> >
> >     # To enable immediate data (i.e., the initiator sends unsolicited data
> >     # with the iSCSI command packet), uncomment the following line:
> >     #
> >     # The default is Yes
> >     node.session.iscsi.ImmediateData = Yes
> >
> >  Looking at the offset printed out by your patch, it is indeed
> >  non-zero for the first RDMA read.  Please correct me if I am
> >  mistaken about this---you must have tested all four variations of
> >  with and without the patches on initiator and target side, but I did
> >  not.
> 
> You are right about the ImmediateData=Yes.
> I really missed that, so after all this patch will break current
> target implementation and
> cause data corruption.
> I suggest to postpone this patch till we implement the iSER HELLO
> message and then add this patch with the corresponding target patch.
> This will allow current initiator to work with current target and new
> initiator work with new target.
> I still think we should do that since future iser implementation will
> probably rely on the spec.

We might as well do the Hello message exchange anyway.  As Ken
points out, the spec would approve.  We could even use this
opportunity to set the IRD and ORD too, but I'm not sure exactly how
that would work in IB once the connection is up.

Here we're not proposing a new bit in the Hello message to indicate
"VA starts before unsol data", but rather lack of Hello message
indicates old initiatior that gets the VA wrong.  That will be easy
to detect in targets.

I wonder if by supporting Hello, that we could remove the use of
private data as specified in the IBTA annex?  These negotiated
parameters (ZBVA and Send w/Inval) could be in the Hello exchange.

We still have the need to put VAs in the iSER header to support the
non-ZBVA case (pre-ConnectX IB), though.  Once we get the Hello
worked out, it might be time to update RFC 5046 to encompass this
hardware model too.

		-- Pete