Sanjeev,
We can set any of those parameters wherever you want as its clearly
a
protocol prerogative.
The one thing that I am trying to avoid is having one parameter being
handled in two ways (It caused me more trouble that it was worth in
the
past and required a lot of logic).
As such we have two consideration when selecting location:
legacy
what layer is the most affected by it
It looks to me that association of sink buffers at targets is mostly
a SCSI
issue and it is dependent on the device type, the relative speed
of the
transport and device, QOS requirements at device. Data is already
in the
SCSI realm (not anymore individual PDUs but sequences that are governed
by
SCSI needs and (including fairness rules between LUs attached to the
same
bus). That is why we have those bursts - iSCSI does not need them -
SCSI
may need them for multiplexing and buffer limitations of its own.
As far
as iSCSI is concerned bursts are just trouble. But without them
a pipe
with a limited window will serve one LU and even beyond it's real
capabilites. The multiplexing capability is needed by SCSI
and is offered
in different ways on different transports. Some "buses" have a "built-in"
multiplexing capability. TCP does not and iSCSI adds it to it by the
"burst
limitation".
All this said and based on an earlier comment made by Bob Snively that
this
could be a good criteria for splitting parameters between text and
mode
pages - I think that the split we have now, even if not built according
to
every developers wet dreams, is reasonable.
Julo
"Sanjeev Bhagat
\(TRIPACE/Zoetermee To:
"Santosh Rao" <santoshr@cup.hp.com>, John
r\)"
Hufferd/San Jose/IBM@IBMUS
<iscsi_t10@sanjeevb cc:
Julian Satran/Haifa/IBM@IBMIL,
hagat.com>
<ips@ece.cmu.edu>
Subject: Re: iscsi : default iscsi mode page
25-09-01 01:58
settings.
Please respond to
"Sanjeev Bhagat
\(TRIPACE/Zoetermee
r\)"
Julian, Santosh,
Can we make all the SCSI mode page paramters be made as login keys?
Why
should they be kept in a seperate mode page at all??
Sanjeev
----- Original Message -----
From: "John Hufferd" <hufferd@us.ibm.com>
To: "Santosh Rao" <santoshr@cup.hp.com>
Cc: "Julian Satran" <Julian_Satran@il.ibm.com>; <ips@ece.cmu.edu>
Sent: Monday, September 24, 2001 10:34 PM
Subject: Re: iscsi : default iscsi mode page settings.
>
> In addition to what Santosh said, If I understand this right,
> I think it is a problem for iSCSI to have to keep going across layers
to
> determine what the values are. Since iSCSI Target will not
see the CDB
> that caused the values to change.
>
> Now if the value in the mode page is only the default, that would
be a
> different issue.
>
> .
> .
> .
> 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
>
>
> Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 09/24/2001 12:28:43
PM
>
> Sent by: owner-ips@ece.cmu.edu
>
>
> To: Julian Satran/Haifa/IBM@IBMIL
> cc: ips@ece.cmu.edu
> Subject: Re: iscsi : default iscsi mode page settings.
>
>
>
> Julian Satran wrote:
>
> > I can sympathize with you wanting to use most of the parameters
in
iSCSI
> -
> > but the values are in fact restrictions that SCSI places on iSCSI.
>
> Julian,
>
> I'm confused by your response.
>
> The SPC-2 description of Disconnect-Reconnect mode page indicates
that :
> "The parameters appropriate to each protocol and their interpretation
for
> that protocol may
> be specified in the individual protocol documents".
>
> FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize
for
> the pSCSI
> transport. Thus, iscsi is within its rights to declare this field
as
> reserved and attach no
> meaning to it in the mode page. The FirstBurstSize can be negotiated
during
> iscsi login
> through a login key.
>
>
> > Nevertheless the discussion is rather academic because SCSI can
hand
> those
> > parameters to iSCSI.
>
> Again, I'm confused by your response. The reasons I'm suggesting
the use
of
> a login key
> instead of the mode page method are :
>
> * More accurate scope (applies only to this I-T
nexus).
>
> * More optimal negotiation and reduced overhead
in the establishment
of
> the I-T nexus. (2
> less SCSI commands per I-T nexus establishment.).
>
> * Enables faster I/O scan times due to lesser on-the-wire
activity
> during I-T nexus
> establishment.
>
> * Allows less room for error in the I-T nexus establishment
(no
> possiblity of failure to
> establish I-T nexus due to mode sense/select
command failure).
>
> * Avoids mode select wars that can occur when target
uses shared mode
> pages.
>
> * Simpler initiator implementations since they
can avoid embedding
SCSI
> command set
> knowledge as well as code to build/parse
SCSI commands. Also, they
can
> avoid extra code
> that is required to snoop for CHECK
CONDITION with (sense key=UA,
ASC
> ="mode parameters
> changed") in order to re-issue a mode
sense to determine new values
> for FirstBurstSize.
>
> * Less code to interact with SCSI ULP application
client to
co-ordinate
> the mode page
> values b/n the ULP & LLP.
>
> * Can use un-solicited data from the very first
scsi command in the
> session.
>
> I don't consider any of the above reasons to be academic and would
like
to
> know which ones
> among the above do you believe are academic and why ?
>
>
> > SCSI can handle those parameters dynamically. iSCSI may have trouble
> > handling this type of negotiation dynamically over several connections.
>
> This is exactly the kind of stuff we don't need and should actually
be
> trying to avoid. What
> good does dynamically changing FirstBurstSize serve ? Dynamically
changing
> FirstBurstSize
> would only be achieved with least side-effects if :
> 1) The mode select implementation on target is not using shared mode
pages.
> 2) The initiator has quiesced I/O prior to issuing the mode select
for
the
> change.
>
> Neither of the above 2 conditions would typically apply and any dynamic
> change of
> FirstBurstSize would only cause initiators to see a bunch of side-effects
> such as :
> a) Active outbound I/Os aborted by the target with a CHECK CONDITION
due
to
> "not enough
> un-solicited data".
> b) UA CHECK CONDITION for "mode parameters changed".
>
> In the interests of simplification and avoiding disruption of active
I/O,
> such modifications
> must be avoided as far as possible. One way to achieve that is to
use a
> login key and make
> it LO.
>
>
> >
> > Resource-wise (as Bob Snively has pointed out) those are SCSI issues.
> >
> > A nice way out would be to ask T10 for a text mode negotiaton :-)
>
> Once again, I'm perplexed by your response. I'm not saying that text
mode
> negotiation is the
> reason I suggest moving this to a login key. The main objective is
to
> isolate such
> negotiation within the iscsi layer in an iscsi specific PDU that
is a
part
> of the iscsi
> login process.
>
> Hope you will consider all of the above factors.
>
> Thanks,
> Santosh
>
> ps : [I wonder if there are any others on this list who care to voice
their
> opinion on this
> issue. (??). ]
>
>
>
>
>
>
