Re: iscsi : default iscsi mode page settings.

[James Smart <james.smart@trebia.com>]

In my mind, this completely illustrates why there should be a clean division
between SCSI device server parameters and transport parameters. Transport
controls should be controlled via the transport - by a transport mechanism, with
the SCSI Device completely unware of the transport (yes, I'm a layering purist).
I've always completely disliked the notion that you had to fully come up on the
transport to send a SCSI command to obtain/change transport information. The
tightly integrated implementations (transport + scsi) may have succeeded earlier
in this argument (especially for FCP and PLDA), but in the end, it breaks down
horrendously as the more complex environments are put together (such as
multi-initiator (aka SAN) environments), or hardware is moved from one
configuration to another (and heaven forbid you can't communicate at the
transport level due to a saved parameter, thus you can't send the scsi command
to change the parameter!).

-- James

"Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote:

> * From the T10 Reflector (t10@t10.org), posted by:
> * "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" <iscsi_t10@sanjeevbhagat.com>
> *
>
> ----- Original Message -----
> From: "Santosh Rao" <santoshr@cup.hp.com>
> To: "IPS Reflector" <ips@ece.cmu.edu>
> Cc: "T10 Reflector" <t10@t10.org>
> Sent: Friday, September 21, 2001 9:27 PM
> Subject: Re: iscsi : default iscsi mode page settings.
>
> > "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.
>
> Rob, Santosh,
>
> I would still go in favour of running a mode sense rather than using a login
> key because
> 1. by providing a value in login key essentially means that we are doing
> some sort of mode select to the target
> 2. if multiple initiators send different values of firstburstsize then
> target has to behave accordingly with all different targets.
>
> This goes completely against the semantics of mode sense and mode select
> defined in SCSI specifications. Any such parameteres are although
> settable/changeable by clients but are mainly the properties of SCSI
> LUs/targets.
>
> Mode sense command from initiator will simplify the logic at target's end as
> well.
>
> regards,
> sanjeev
>
> >
> > >
> > > > 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.
> >
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo@t10.org