Re: iscsi : default iscsi mode page settings.

[Santosh Rao <santoshr@cup.hp.com>]

"Elliott, Robert" wrote:

> If an initiator cares about any settings it better run MODE SENSE
> to set them.  In a multi-initiator environment with various kinds
> of reset events occuring on the SAN, an initiator can't be sure
> of the state of a mode page.  (see the tape problem discovered by
> Veritas in FCP-2 public review; tape mode pages were reset without
> the knowledge of the application, breaking backups).

Rob,

Is'nt this all the more reason to avoid setting FirstBurstSize through a
mode page and use a login key for this ? Shared mode pages can cause some
strange side effects on I/Os that are using un-solicited data.

>
> > Logical Unit Control Mode Page
> > ==============================
> > This mode page definition can be removed from the iscsi draft since it
> > governs per-LUN state information and LUN state is the realm of the
> > SCSI ULP. In particular, it is the SCSI ULP that decides whether to
> > enable/disable CRN, since CRN is generated by the SCSI ULP.
> >
> > Thus, it is un-clear why the "Enable CRN" is negotiated at a
> > protocol level & not at a SCSI ULP mode page such as the
> > Control Mode Page. (??).
> >
> > Could anybody comment on why CRN (a ULP feature) needs to be
> > enabled in an iscsi protocol mode page ?
> > Perhaps, for FCP it made sense to negotiate something like
> > "Enable CRN" in FCP specific mode pages, since early revisions
> > of FCP did'nt specify the CRN field in FCP_CMD IU and so,
> > the "Enable Precise Delivery" (EPDC) bit was required to
> > be queried/set using mode sense/select, prior to using CRN.
> >
> > Since iscsi supports CRN in its scsi command pdu from its
> > initial rev, I don't see why "Enable CRN" is needed to be done
> > at the iscsi protocol level.
>
> You're right that history is the reason.  CRN was created in FCP-2
> and wasn't added to SAM-2 until recently.  Thus, it was
> protocol-specific.  The Logical Unit Control mode page was
> created as a new page separate from the Port Control mode page
> specifically to host the EPDC bit, which does not have
> target-wide scope like the other Port Control mode page fields.
>
> The Control mode page doesn't have any fields whose implementation
> depends on the protocol, so it's not really a good home for this.
> The Disconnect-reconnect mode page does, but CRN doesn't really
> fit with its other fields.  Since FCP-2 has already committed to
> using the Logical Unit Control mode page, it makes sense for
> iSCSI to do the same.

Does the EPDC bit verify the CRN capabilities of both the target FCP layer
and the target SCSI ULP (device server) ? One would think the capabilities
of the 2 layers need to be checked through seperate bits. The device
server's ability to support CRN is a SCSI ULP feature and seems more like a
bit in the Control Mode Page. (does not exist today ?). The target FCP's
CRN capability is tested through the FCP specific EPDC bit in the FCP
specific lun control mode page.

For iSCSI, no protocol specific test should be required since iscsi always
supports CRN. Regarding the device server's support for CRN, this seems
like a better fit in the Control Mode Page.

Regards,
Santosh

> CRN on one side, a bridge probably wants it enabled on the other
> side so it doesn't have trouble reordering packets.  By using
> the same page the bridge can just pass through the Mode
> Select/Mode Sense data when the software issues those commands.

> If a different page was used, it might need to generate
> additional Mode Select/Mode Sense commands and translate
> the information.  This is also why I think EMDP needs to
> remain controlled by the Port Control mode page, rather than
> just be delegated to text key exchange.
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard