Subject: Re: ImmediateData Text Parameter Negotiation

From: "Julian Satran" <[email-masked]>
Date: Wed, 19 Sep 2001 08:23:33 +0300

I'll fix them. Julo

"BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <[email-masked]> on
18-09-2001 19:04:39

Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"
      <[email-masked]>

To:   [email-masked], Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  ImmediateData Text Parameter Negotiation

Julian,

Appendix D24 (ImmediateData) does not describe the result of negotiation if
the two sides differ. I presume that since the default is "yes", then only
if both sides agree to "no" is immediate data turned off.  Please can this
be stated.

Additionally, I feel that the default value for ImmediateData should be
"no".

Similarly, there is no statement on MaxOutstandingR2T.  Presumable the
minimum is selected.

Matthew Burbridge
Senior Development Engineer
NIS-Bristol
Hewlett Packard
Telnet: 312 7010
E-mail: [email-masked]

---

From: Dave Sheehy <[email-masked]>
Date: Wed, 19 Sep 2001 10:09:45 PDT

> if both sides agree to "no" is immediate data turned off.  Please can this

I think that if either side says "no" then it's turned off. If one side
doesn't support immediate data and says "no" no amount of cajoling (saying
"yes") from the other side is going to change that.

> Additionally, I feel that the default value for ImmediateData should be

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

---

From: [email-masked] (Sandeep Joshi)
Date: Wed, 19 Sep 2001 13:58:54 -0400 (EDT)

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 ?

-Sandeep

---

From: Dave Sheehy <[email-masked]>
Date: Wed, 19 Sep 2001 16:12:25 PDT

> 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

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 20 Sep 2001 09:12:46 +0300

Testing you certainly should (as we did when we suggested that ages ago).
I addition it was pointed out several times on this list (by your
colleagues too) that out of the 2 forms of unsolicited data (immediate and
separate PDU) immediate are easier to handle by the target as no additional
matching (with ITT) to perform.

      Regards,
     Julo

                    Dave Sheehy                                                                   
                    <[email-masked]       To:     [email-masked] (IETF IP SAN Reflector)   
                    ilent.com>                  cc:                                               
                    Sent by:                    Subject:     Re: ImmediateData Text Parameter     
                    [email-masked]        Negotiation                                      

                    20-09-01 02:12                                                                
                    Please respond to                                                             
                    Dave Sheehy                                                                   

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