RE: iscsi : iscsi parameter default values

["Eddy Quicksall" <Eddy_Quicksall@ivivity.com>]

First, realize I just want to give information as I see it from an objective
standpoint.

Regarding your reply below, login is not cached so the "immediate data"
techniques used there are quite different then the techniques used during
full feature phase in legacy cache.

In another mail, I explained why some legacy cache implementations would
have to be changed and cache is probably the last thing you would want to
change if you are in a "time to market" crunch. Remember, this is not in the
transport layer.

The thing we should probably be looking at is "what requires the least
number of round trips and are the round trips really significant".

Eddy

-----Original Message-----
From: John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Monday, October 01, 2001 6:33 PM
To: Dev - Platys
Cc: Eddy Quicksall; ips@ece.cmu.edu
Subject: RE: iscsi : iscsi parameter default values



You will need the same type of Immediate Data handling code to handle the
Login.  The Login Parameters are in the extended Data Section of the PDU.
So you have to have that code anyway.

Given that you have to have the code anyway, in both cases
ImmediateData=Yes and No -- Yes is the simplest, the best performing, and
the lowest overhead, so Yes should be the default.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


"Dev - Platys" <deva@platys.com>@ece.cmu.edu on 10/01/2001 02:39:57 PM

Sent by:  owner-ips@ece.cmu.edu


To:   "Eddy Quicksall" <EQuicksall@mediaone.net>, <ips@ece.cmu.edu>
cc:
Subject:  RE: iscsi : iscsi parameter default values



Thats a good point.

Deva
Adaptec


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Eddy Quicksall
Sent: Monday, October 01, 2001 2:11 PM
To: ips@ece.cmu.edu
Subject: RE: iscsi : iscsi parameter default values


Looking at this from another view point ...

Isn't support of R2T required anyway because the Expected Data Transfer
Length may exceed the FirstBurstSize?

So, wouldn't that make "no" the "lowest common denominator"? If so, I would
think that "no" would therefore be the default.

Just food for thought.

Eddy