RE: ImmediateData Text Parameter Negotiation

["Wheat, Stephen R" <stephen.r.wheat@intel.com>]

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