Subject: RE: iscsi : default iscsi mode page settings.

From: "John Hufferd" <[email-masked]>
Date: Wed, 26 Sep 2001 07:36:34 -0700

Does anyone know of where a Legacy function would exist, in the Host which
would do anything with FirstBurstSize?  I am assuming it would have to be
in the SCSI Device Driver, and since we have iSCSI instead, that may not be
an issue.
I could be wrong but I do not think that it occures in the SCSI Class
Drivers.
And I do not think it ocures in the File Systems, so where does this Legacy
function we are worried about occure?
If it is in the SCSI Device Driver it is NOT an 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: [email-masked]

"CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>@ece.cmu.edu on
09/25/2001 10:14:12 PM

Sent by:  [email-masked]

To:   "[email-masked]'" <[email-masked]>, ips <[email-masked]>
cc:
Subject:  RE: iscsi : default iscsi mode page settings.

>Julian and Santosh,
>
>Whether FirstBurstSize should be a text key or not,
>IMHO, is (mostly) dependent on the current implementations.
>Santosh rightly pointed out several drawbacks of
>mandating a new set of mode select/sense operations
>that are totally iSCSI-specific since the legacy SCSI
>stack (class drivers, services/midlayer) will have no
>clue about them.  OTOH, if most of today's SCSI stacks
>_do_ perform this mode parameter manipulation in disconnect-
>reconnect mode page, that would be a strong argument to
>leave FirstBurstSize as a mode page parameter.

Anything iSCSI specific should attempt to follow other iSCSI
methods of configuration (e.g. text keys).  We should really
be driving towards a single method of parameter negotiation
and configuration - especially when the legacy methods
have no clue about the new parameters and would require upgrades.

Paul

---

From: Santosh Rao <[email-masked]>
Date: Wed, 26 Sep 2001 10:39:38 -0700 (PDT)

John,

I suspect that in most cases these mode page settings would not be done, 
since most stacks are still SCSI-2 based.
Hence, any SCSI LLPs that do provide support for these transport specific
mode pages (ex : FCP-2 implementations) would probably be issuing these 
mode sense/select's from within the LLP (miniport driver, HBA driver, etc).

The file system and wedge drivers do not muck with these, as you already
pointed out.

Since these mode pages have transport specific semantics, any SCSI ULP
(ex : class driver) that attempts to issue mode sense/select for transport
specific mode pages would first need to interact with some transport
specific code to determine which transport is being used and what mode
page format is to be used. Thus, any such class driver would need an
upgrade to understand the iscsi transport specific mode pages.

Even if there are some management applications that may be trying to set
these parameters through pass thru mode sense/select commands, they would
need to now be upgraded to understand iscsi specific versions of these
transport mode pages. Further, any such management app. would also need to
develop mechanisms to issue pass-thru text commands or some other
mechanism if it wished to tweak iscsi parameters.

Hence, I agree with you that there should not be any legacy issue here.
Any layer or management app that mucks with iscsi parameters will need an
upgrade anyway and they might as well be upgraded to use a single
mechanism, login keys.

I think we've beaten this issue to death, and suggest that we call for
consensus on this issue and move onto other issues.

Regards,
Santosh

-- 
#################################
Santosh Rao
Software Design Engineer,
HP, Cupertino.
email : [email-masked]
Phone : 408-447-3751
#################################