RE: ImmediateData Text Parameter Negotiation

["Eddy Quicksall" <EQuicksall@mediaone.net>]

I vote for NO. My reason is as follows:

 2.2.4 Text Mode Negotiation says:
 For numerical (and binary) negotiations, the responding party SHOULD
 respond with the required key but the offering party MUST accept no
 answer as equivalent to answering with the default value.

If the target negotiates for NO and the initiator does not answer, then YES
is assumed because that is the default. So if the target can't do immediate,
it would have to close the connection. It could be argued that that would be
OK because the initiator should probably have answered, but I'm not crazy
about that argument.

I don't agree that YES is easier ... in my first driver, I found that it was
much easier to use the R2T because it related very closely to the phase
change in pSCSI (i.e., you don't change phase until you are ready to receive
the data).

If the default is changed to NO, how does that hurt anything? All the
initiator needs to do is negotiate for YES.

Eddy

-----Original Message-----
From: Santosh Rao [mailto:santoshr@cup.hp.com]
Sent: Wednesday, September 19, 2001 8:23 PM
To: ips@ece.cmu.edu
Subject: Re: ImmediateData Text Parameter Negotiation



The default settings should be conservative. Anyone offering advanced
features
must be preapred to do extra work to offer the same and this involves having
to
explicitly negotiate those keys to set it to aggressive values.

In keeping with other scsi models such as scsi mode page settings, defaults
must always be set to conservative values.

- Santosh


"Wheat, Stephen R" wrote:

> As both an iSCSI Target and RAID building blocks supplier, I agree with
John
> and Sandeep that ImmediateData=Yes as default.  In particular, for the
very
> reasons attributed to John below.
>
> Stephen
>
> -----Original Message-----
> From: Dave Sheehy [mailto:dbs@acropora.rose.agilent.com]
> Sent: Wednesday, September 19, 2001 4:12 PM
> To: ips@ece.cmu.edu
> Subject: Re: ImmediateData Text Parameter Negotiation
>
> >
> > I'd prefer "yes" as the default.
> >
> > Targets with memory constraints should limit the
> > maxCmdSN they advertise (allow only one cmd in the
> > worst case.. )
> >
> > What are the other reasons why "no" would be preferred ?
>
> Historical I suppose. Fibre Channel initially didn't support immediate or
> unsolicited data. Unsolicited data cannot be directly placed so it
requires
> extra work and buffering on the part of the target which isn't readily
> accelerated in HW and Fibre Channel's emphasis was on enabling HW
> acceleration.
>
> Recently (relatively anyway), FCP-2 added immediate data commands back
into
> Fibre Channel and some Fibre Channel folks mentioned on this list that it
> was a good thing. Yet, to date, I have seen no customer interest in that
> functionality so it makes me wonder what the fuss is about.
>
> John's argument has been that we need immediate/unsolicited data in order
to
> fill long fat pipes. He also has said the extra work required on the
target
> side is worth it. I want to test those notions with the other systems and
> peripheral (e.g. storage array) vendors.
>
> Dave Sheehy
>
> >
> > -Sandeep
> >
> > > > Additionally, I feel that the default value for ImmediateData should
> be
> > > > "no".
> > >
> > > This comes down to what do we think the most common default behavior
is
> > > going to be. So far IIRC, the only person who has explicitly stated
that
> > > immediate data support will be the common default behavior has been
John
> > > Hufferd. I'd like to hear the opinions of the rest of the list.
> > >
> > > Dave Sheehy