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

[Ken Sandars]

Hi all,

It appears the current Linux iSER initiator does not send the HELLO message when the connection transits to full feature phase. The stgt target also ignores this message (if it were to appear). Both of these implementations use a non-conformant iSER header (they add write_va and read_va fields, which incidentally do not appear to be used). Are these changes documented anywhere in the IB domain, or are these variations needed for another reason?

If these deviations from the RFC are not needed and were to be fixed (along with the offset fix), then these implementations can detect the current mode of operation by examining the size of the iSER header received. The choice to proceed in the broken way, or to terminate the connection (with big loud error messages) is the implementor's choice. Either way, the issue is detected and corruption avoided.

Thoughts?

Cheers
Ken



> Date: Tue, 29 Apr 2008 13:05:16 -0400
> From: pw at osc.edu
> To: dorfman.eli at gmail.com
> CC: stgt-devel at lists.berlios.de; rdreier at cisco.com; general at lists.openfabrics.org; mako at almaden.ibm.com; ips at ietf.org; open-iscsi at googlegroups.com
> Subject: Re: [Stgt-devel] [ofa-general] Re: [Ips] Calculating the VA in iSER	header
> 
> dorfman.eli at gmail.com wrote on Thu, 17 Apr 2008 14:13 +0300:
> > On Wed, Apr 16, 2008 at 6:46 PM, Roland Dreier <rdreier at cisco.com> wrote:
> > >  > Agree with the interpretation of the spec, and it's probably a bit
> > >   > clearer that way too.  But we have working initiators and targets
> > >   > that do it the "wrong" way.
> > >
> > >  Yes... I guess the key question is whether there are any initiators that
> > >  do things the "right" way.
> > >
> > >
> > >   > 1. Flag day: all initiators and targets change at the same time.
> > >   > Will see data corruption if someone unluckily runs one or the other
> > >   > using old non-fixed code.
> > >
> > >  Seems unacceptable to me... it doesn't make sense at all to break every
> > >  setup in the world just to be "right" according to the spec.
> > 
> > This will break only when both initiator and target will use
> > InitialR2T=No, which means allow unsolicited data.
> > As far as I know, STGT is not very common (and its version in RHEL5.1
> > is considered experimental). Its default is also InitialR2T=Yes.
> > Voltaire's iSCSI over iSER target also uses default InitialR2T=Yes.
> > So it seems that nothing will break.
> 
> I finally got a chance to look at this just now.  I think you mean
> default is InitialR2T=No above, which means no unsolicited data.
> That is the default case, and true, the two different meanings
> of the initiator-supplied VA coincide.
> 
> 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.
> 
> Hence I am still a bit unhappy about having to deal with the
> fallout, with no way to detect it.  For our local use, I'll keep an
> older version of stgt in use until we switch to a new kernel, then
> merge up the target side change.  It is a bother, but I can deal
> with it.  For other institutions, this lockstep upgrade requirement
> will not be obvious until they debug the resulting data corruption.
> 
> Still, I do understand why it would be nice to conform to the spec,
> and it is maybe a bit cleaner that way too.  Maybe you can help with
> the bug reports on stgt-devel during the transition, and maintain
> and publish a patch to let it work with old kernels.
> 
> 		-- Pete
> _______________________________________________
> Stgt-devel mailing list
> Stgt-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/stgt-devel

_________________________________________________________________
Find the job of your dreams before someone else does
http://mycareer.com.au/?s_cid=596064 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/stgt-devel/attachments/20080430/9e698849/attachment.html